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PREFACE 


The  Transit  Reliability  Information  Program  (TRIP)  is  a 
government-initiated  program  to  assist  the  transit  industry 
in  satisfying  its  need  for  transit  reliability  information. 
TRIP  provides  this  assistance  through  the  operation  of  a 
national  reliability  Data  Bank.  This  Data  Bank  collects, 
stores,  and  analyzes  data  which  is  being  generated  by 
transit  operators  in  the  course  of  revenue  service  operation 
and  equipment  maintenance.  The  results  of  periodic  analyses 
of  the  stored  data  are  distributed  to  TRIP  participants  and 
users . 

TRIP  has  been  designed  as  a three-phased  program. 
Phase  I consists  of  defining  the  functional  and  operational 
requirements  of  the  TRIP  Data  Bank,  and  designing, 
implementing,  and  operating  an  Experimental  Data  Bank  for 
the  purpose  of  evaluating  the  design  concepts  of  the 
(full-scale)  Data  Bank  on  a prototype  scale.  Phase  II 
consists  of  merging  the  two  EDBs  into  a single  data  bank  and 
expanding  the  scope  of  the  data  bank  to  include  all  aspects 
of  vehicles  involved.  Phase  III  will  be  the  expansion  of 
the  TRIP  Data  Bank  to  include  other  classes  of  equipment. 

This  report  contains  a summary  of  the  results  achieved 
and  conclusions  reached  during  initial  phase  of  the  Transit 
Reliability  Information  Program.  This  "Phase  I Report"  has 
been  prepared  by  the  Dynamics  Research  Corporation  (DRC), 
Wilmington,  Massachusetts,  under  Contract  Number 

DOT-TSC- 1 559 , issued  by  the  U.S.  Department  of 

Transportation  (DOT) , Transportation  Systems  Center  (TSC) , 
on  behalf  of  the  Office  of  Safety  and  Product  Qualification 
of  the  Urban  Mass  Transportation  Administration  (UMTA) , 
Office  of  Technology  Development  and  Deployment,  U.S.  DOT. 

The  authors  would  like  to  acknowledge  with  gratitude 
the  assistance  provided  by  Roberta  Gosselin  in  the 

preparation  and  production  of  this  report. 
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1 . EXECUTIVE  SUMMARY 


This  report  contains  a summary  of  the  results  achieved  and 
conclusions  reached  during  the  initial  phase  of  the  Transit 
Reliability  Information  Program  (TRIP)  . This  "Phase  I Report" 
has  been  prepared  by  the  Dynamics  Research  Corporation  (DRC) , 
Wilmington,  Massachusetts,  under  Contract  Number  DOT-TSC-1 559 , 
issued  by  the  U.S.  Department  of  Transportation  (DOT), 
Transportation  Systems  Center  (TSC) , on  behalf  of  the  Office  of 
Safety  and  Product  Qualification  of  the  Urban  Mass  Transportation 
Administration  (UMTA) , Office  of  Technology  Development  and 
Deployment,  U.S.  DOT. 

TRIP  is  a government-initiated  program  to  assist  the  transit 
industry  in  satisfying  its  need  for  transit  reliability 
information.  TRIP  provides  this  assistance  through  the  operation 
of  a national  reliability  Data  Bank.  This  Data  Bank  collects, 
stores,  and  analyzes  data  which  is  being  generated  by  transit 
operators  in  the  course  of  revenue  service  operation  and 
equipment  maintenance.  The  results  of  periodic  analyses  of  the 
stored  data  are  distributed  to  TRIP  participants  and  users. 

TRIP  has  been  designed  as  a three-phased  program.  Phase  I 
consists  of: 


• Definition  and  scoping  of  the  functional  and  operational 
requirements  of  the  TRIP  Data  Bank; 

• Design,  implementation,  operation,  and  enhancement  of  a 
Rail  Rapid  Vehicle  (RRV)  Experimental  Data  Bank  (EDB)  for 
the  purpose  of  evaluating  the  design  concepts  of  the 
(full-scale)  TRIP  Data  Bank  on  a prototype  scale; 

• Design,  implementation,  operation,  and  enhancement  of  an 
EDB  for  Buses. 


Phase  II  consists  of  merging  the  two  EDBs  into  a single  data 

bank  and  expanding  the  scope  of  the  data  bank  to  include  all 

aspects  of  the  vehicles  involved.  Phase  III  will  be  the 
expansion  of  the  TRIP  Data  Bank  to  include  other  classes  of 
equi  pment . 

TRIP  is  currently  in  Phase  I.  The  purpose  of  this  report  is 
to  present  a summary  of  the  accomplishments  and  recommendations 
resulting  from  the  design,  development,  and  implementation  of  the 
RRV  EDB  under  Contract  Number  DOT-TSC-1 559 . Prior  to  the  TRIP 
Critical  Design  Review  (CDR)  on  March  31,  1980,  "Phase  I"  of 

Contract  Number  DOT-TSC-1559  and  "Phase  I"  of  the  TSC  TRIP 
Implementation  Plan  were  concurrent  events.  The  net  effect  of 

the  CDR  was  to  extend  the  duration  of  Phase  I of  the 

Implementation  Plan,  postponing  the  commencement  of  Phase  II  by 


1 


15  - 21  months 


The  original  purpose  of  Phase  II  of 
provide  transition  support  for  the  lead-in  to 
TRIP  Implementation  Plan.  Because  of  the  CDR 


the  contract  was  to 
Phase  II  of  the  TSC 
outcome,  however, 
the  objective  of  Phase  II  of  the  contract  was  redirected  from  a 
posture  of  maintaining  EBD  operation  until  the  full-scale  Data 
Bank  was  established,  to  maintaining  EDB  operation  until  a 
"continuation  contract"  could  be  issued  to  continue  EDB 
operation,  refinement,  and  expansion  as  recommended  by  the  CDR 
Committee.  Even  though  Phase  I of  the  contract  "expired"  in 


September  1980,  the  work  of  Phase  I 
present.  Therefore,  the  period  covered  by 
September  1978,  when  the  contract  was 
1981.  The  activities  conducted  during  the 
Number  DOT-TSC-1559  will  be  summarized 


continued  to  the 
report  is  from 
March 

remainder  of  Contract 
in  the  "Final  Technical 


has 
this 

awarded,  through 


Report"  to  be  produced  at  the  conclusion  of  the  contract 


1.1  CONCLUSIONS  AND  RECOMMENDATIONS 


The 

followi 

ng 

is  a 

summary 

0 

f 

the 

conclusio 

ns 

and 

recommendations 

pr  e 

sented 

in  the 

m 

ai 

n body 

of  this 

Ph 

ase  I 

Report : 

• 

The  natio 

nal 

Data 

Bank  conce 

pt 

h 

as  been 

proven  to 

be 

both 

possible 

and 

pr  act 

ical  through 

the  opera 

tion  of  the 

TRIP 

Exper iman 

tal 

Data 

Bank  (EDB) 

• 

• 

The  activ 

e p 

artic i 

pation  and 

i 

nt 

erest  in 

TRIP  by 

the 

APTA 

TRIP  Liai 

son 

Board 

member sh 

ip 

during 

Phase  I 

on 

the 

program 

ind 

icate 

that  TRI 

P 

h 

as  been 

demonstr a 

ted 

as  a 

viable  ce 

ntr 

al  source  of  tra 

ns 

it 

reliability  inform 

at  ion 

which : 

is  fie 

xible  and 

responsiv 

e 

in 

meeting 

the  need 

S 0 

f its 

users ; 

provid 

es 

maximum  informat 

io 

n 

at  minim 

urn  cost 

to 

the 

user . 

• Expansion  and  operation  of  the  full-scale  Data  Bank 
requires : 

knowledgeable  personnel; 
dedicated  resources; 
a systematic  expansion  approach; 
orderly  operation. 

Specific  conclusions  of  Phase  I,  based  upon  the  comments  of 
the  Critical  Design  Review  (CDR)  Committee  expressed  during  the 
first  CDR  of  TRIP,  are  as  follows: 
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• The  full  benefit  of  TRIP  has  yet  to  be  realized  --  the 
major  benefits  will  be  derived  from  long-term  operation 
of  the  Data  Bank; 

• Dynamics  Research  Corporation  (DRC)  should  continue  to 
operate  the  TRIP  Experimental  Data  Bank  for  an  additional 
year  in  order  to  allow  more  time  to: 

explore  the  full  potential  of  the  system; 

develop  output  reports; 

refine  system  operation; 

develop  more  confidence  in  the  system; 

• A second  CDR  should  take  place  one  year  hence  to  again 
consider  the  timing  of  EDB  expansion  into  a full-scale 
system . 

These  conclusions  form  the  basis  of  recommendations  for  the 
implementation,  expansion,  and  operation  of  the  full-scale  Data 
Bank.  Generally,  recommendations  can  be  made  in  the  areas  of 
alternative  approaches  to  TRIP  operation,  maintenance,  and 
expansion  (0,M&E),  expansion  of  the  Data  Bank  from  its 
experimental  to  full-scale  configuration,  and  long-term  operation 
of  the  Data  Bank.  Specifically,  these  recommendations  can  be 
summarized  as  follows: 

• Recommendations  for  Data  Bank  expansion: 

Systematic  approach  to  expansion: 

o Completion  of  EDB  Generic  Parts  Lists; 
o Other  vehicle  types  at  EDB  properties; 
o Vehicle  types  at  other  transit  properties; 
o Other  classes  of  equipment; 

Maintain  consistency  during  expansion: 

o Generic  Parts  List  development; 
o Data  handling  procedures; 
o Data  Bank  operation; 

Technical  support  for  expansion: 

o Increased  labor  force; 
o Training/familiarization; 

• Recommendations  for  Data  Base  operation: 

Knowledgeable  personnel: 

o Data  quality  preservation; 
o Accuracy  and  validity  of  output  reports; 

0 Transit  property  interface; 


3 


Dedicated  resources  (personnel  and  automated  data 
processing  equipment) : 

o Timeliness  of  output  reports; 
o Input  data  volume; 

Engineering  support; 

o Responding  to  "special  requests"; 
o Resolving  data  anomalies. 


1.2  INTRODUCTION  AND  SUMMARY 


This  document  is  a summary  of  the  accomplishments  of  TRIP 
Phase  I along  with  the  results  achieved  and  conclusions  reached 
during  Phase  I of  Contract  Number  DOT-TSC- 1 559 . Phase  I 
consisted  of  two  major  activities  covering  the  planning, 
designing,  and  testing  of  a small-scale  (experimental)  data 
bank.  The  first  activity  was  to  define  and  document  TRIP 
functional  and  operational  requirements  necessary  to  satisfy 
program  requirements.  The  second  activity  was  to  develop, 
establish,  and  operate  an  Experimental  Data  Bank  (EDB),  as  a 
prototype  of  the  full-scale  TRIP  Data  Bank,  for  the  purpose  of 
evaluating  the  proposed  methodology. 

An  overview  of  the  Transit  Reliability  Information  Program 
(TRIP)  is  presented  in  Section  2.  This  background  material 
covers  the  goals  of  the  program,  a description  of  the  three 
phases  of  the  program,  and  the  historical  development  of  Phase  I 
of  the  program.  Also,  a list  of  documents  produced  under  this 
contract  is  presented  for  reference  purposes. 

Section  3 presents  an  evaluation  of  Phase  I activities. 
This  evaluation  is  based,  first,  on  an  assessment  of  TRIP 
concepts  set  forth  at  the  beginning  of  the  program.  Second,  the 
evaluation  addresses  an  assessment  of  the  experience  gained 
through  and  conclusions  of  the  Experimental  Data  Bank  operation. 
Third,  projections  of  the  full-scale  TRIP  Data  Bank  are  presented 
based  upon  the  EDB  experience.  Fourth,  a summary  of  the  results 
and  conclusions  of  the  first  Critical  Design  Review  (CDR) 
Committee  is  presented. 

Section  4 provides  a summary  of  characteristics  and 
requirements  which  must  be  considered  in  the  design, 

implementation,  and  operation  of  a full-scale  TRIP  Data  Bank. 
This  summary  is  based  upon  the  experience  gained  through  the 
design,  implementation,  and  operation  of  the  TRIP  EDB  for  Rail 
Rapid  Vehicles  (RRV),  and  on  the  feedback  received  from 
representatives  of  the  operating  transit  properties  who  have 
actively  participated  in  the  program. 
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Recommendations  for  the  implementation,  expansion,  and 
operation  of  the  full-scale  TRIP  Data  Bank  are  presented  in 
Section  5.  Alternative  approaches  to  the  implementation  of  the 
full-scale  Data  Bank  are  discussed  in  this  section,  as  well  as 
considerations  for  the  expansion  of  the  Data  Bank  from  its 
experimantal  to  full-scale  configuration  and  subsequent  long-term 
operation . 

A summary  of  the  results  and  conclusions  reached  during  each 
of  the  twelve  tasks  of  Contract  Number  DOT-TSC-1559  is  presented 
in  Section  6.  Each  task  is  discussed  in  terms  of  its  activities, 
the  approach  used  to  perform  the  task,  and 
conclusions  reached. 


the  results  and 
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2.  BACKGROUND 


This  section  presents  an  overview  of  the  Transit  Reliability 
Information  Program  (TRIP).  This  background  material  covers  the 
goals  of  the  program,  a description  of  the  three  phases  of  the 
program,  and  the  historical  development  of  Phase  I of  the 
program.  A list  of  documents  produced  under  the  Phase  I support 
contract  ( DOT-TSC-1 559)  is  also  provided. 


2.1  OVERVIEW 


The  Transit  Reliability  Information  Program  (TRIP)  is  a 
government  initiated  response  to  an  acknowledged  need  to  collect 
and  analyze  rail  transit  equipment  reliability  data  on  a national 
level.  The  goals  of  TRIP  are  to: 


• Amalgamate  current  reliability  efforts  within  the  transit 
industry,  and  provide  a focal  point  for  a consolidated 
reliability  effort; 

• Promote  uniform  reliability  related  definitions  for  the 
transit  industry; 

• Provide  a central  repository  for  voluntary  submittal  of 
transit  industry  field  failure  data; 


• 

Provide 
data ; 

uniform  processing 

and  analysis 

of 

reliability 

• 

Provide 

means  for  periodic 

d i str ibut ion 

of 

reliability 

data  to 

potential  users; 

• 

Pr ov ide 

data  for  factual 

comparison 

of 

reliability 

between  related  equipments; 

• Provide  substantive  data  for  specifying  new  equipment 
procurements,  and  justifying  product  improvement  projects 
and  supporting  system  analysis  programs. 


TRIP  has  been  designed  as  a three-phased  program.  Phase  I 
consists  of: 


• Definition  and  scoping  of  the  functional  and  operational 
requirements  of  the  TRIP  Data  Bank; 

• Design,  implementation,  operation,  and  enhancement  of  a 
Rail  Rapid  Vehicle  (RRV)  Experimental  Data  Bank  (EDB)  for 
the  purpose  of  evaluating  the  design  concepts  of  the 
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(full-scale)  TRIP  Data  Bank  on  a prototype  scale; 

• Design,  implementation,  operation,  and  enhancement  of  an 
EDB  for  Buses. 


Phase  II  consists  of  merging  the  two  EDBs  into  a single  data 
bank  and  expanding  the  scope  of  the  data  bank  to  include  all 
aspects  of  vehicles  involved.  Phase  III  will  be  the  expansion  of 
the  TRIP  Data  Bank  to  include  other  classes  of  transit 
equi pment . 

TRIP  is  currently  in  Phase  I.  The  initial  TRIP  support 
contract  was  issued  to  the  Dynamics  Research  Corporation  in 
September,  1978,  by  the  U.S.  Department  of  Transportation  (DOT), 
Transportation  Systems  Center  (TSC)  for  the  purpose  of  planning 
and  establishing  a program  to  collect  and  evaluate  reliability 
information  on  new  and  existing  transit  vehicles.  This  contract 
focused  on  TRIP  for  Rail  Rapid  Vehicles  (RRV-TRIP)  and  included 
the  definition  and  scoping  of  the  full-scale  TRIP  Data  Bank. 

The  American  Public  Transit  Association  (APTA),  under 
separate  contract  to  TSC,  established  the  TRIP  Liaison  Board 
consisting  of  representatives  from  U.S.  rail  transit  authorities 
and  transit  equipment  manufacturers.  The  Liaison  Board  has 
provided  continuous  guidance  for  the  development  of  TRIP  and  the 
EDB  through  a series  of  periodic  meetings.  From  the  Liaison 
Board  membership,  six  transit  authorities  volunteered  at  the 
contract  "kick-off  meeting"  to  participate  in  the  development  of 
TRIP  by  supplying  data  to  the  EDB.  The  six  properties  are: 


BART 

CTA 

GCRTA 

NYCTA 

PATCO 

WMATA 


Bay  Area  Rapid  Transit  District; 

Chicago  Transit  Authority; 

Greater  Cleveland  Regional  Transit  Authority; 
New  York  City  Transit  Authority; 

Port  Authority  Transit  Corporation; 

Washington  Metropolitan  Area  Transit  Authority. 


2.2  PROGRAM  CHRONOLOGY 


The  development  of  the  TRIP  Data  Bank  began  with  an 
investigation  of  existing  reliability  data  banks  and  an  analysis 
of  the  data  collection  and  reporting  approaches  being  used  in  the 
transit  industry.  Particular  emphasis  was  placed  upon  the  six 
EDB  properties.  The  results  of  these  investigations  were  used  to 
formulate  a functional  definition  of  the  TRIP  Data  Bank.  Each  of 
the  required  TRIP  Data  Bank  functions  was  further  defined  into 
modular  "elements"  which  were  then  translated  into  preliminary 
design  requirements  and  specifications. 
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Part  of  the  TRIP  Data  Bank  design  included  the  development 
of  a uniform  system  of  transit  vehicle  component  identification. 
This  parallel  activity  resulted  in  the  formulation  of  the 
"Generic  Part  Number"  (GPN) , a code  by  which  equipment  of  similar 
function  is  classified  and  grouped  according  to  that  function. 
The  purpose  of  the  GPN  is  to  provide  a common  numbering  system  to 
which  the  individual  part  numbering  systems  used  at  the  various 
transit  properties  can  be  cross-referenced.  The  GPN  is  the  major 
"key"  by  which  component  data  is  stored  in  the  TRIP  Data  Bank 
and,  because  of  its  orientation  toward  equipment  function, 
provides  a means  for  efficient  data  retrieval  in  support  of 
analytical  comparison  of  functionally  similar  equipment. 
Procedures  were  subsequently  developed  for  preparing  the  "Generic 
Parts  List"  (GPL),  the  cross-reference  table  of  transit  property 
part  numbers  versus  Generic  Part  Numbers. 

The  design  and  implementation  of  the  Experimental  Data  Bank 
began  early  in  1979.  The  purpose  of  the  EDB  was  to  provide  a 
model  or  prototype  of  the  TRIP  Data  Bank  so  that  the  various 
aspects  of  the  emerging  Data  Bank  design  could  be  tested  and 
refined  prior  to  full-scale  implementation.  The  TRIP  Liaison 
Board  recommended  three  rail  vehicle  subsystems  (doors  and  door 
controls,  propulsion,  and  friction  brakes)  for  use  as  "pilot 
equipment"  in  the  EDB. 

Following  the  successful  completion  of  the  Software 
Acceptance  Test,  the  TRIP  Experimental  Data  Bank  began  operation 
on  August  6,  1979,  with  the  input  of  July  data  from  BART  and 

WMATA.  EDB  refinement  and  expansion  have  been  on-going 
activities  since  the  initiation  of  operation.  Expansion  of  the 
"input  side"  of  the  EDB  continued  with  the  inclusion  of  CTA  and 
PATCO  in  November,  1979,  and  NYCTA  in  February,  1980.  (GCRTA 
will  be  brought  on-line  during  in  1981).  The  EDB  currently 
contains  data  going  back  to  August  1,  1979,  for  CTA  and  PATCO, 
and  July  1,  1979,  for  BART,  NYCTA,  and  WMATA. 

The  first  EDB  Output  Report  was  published  in  September  1979, 
and  contained  the  July  data  for  BART  and  WMATA.  The  TRIP  Liaison 
Board  reviewed  the  report  and  recommended  several  modifications 
to  format  and  content.  EDB  Output  Reports  were  subsequently 
published  in  November,  1979  (August  and  September  data),  March, 
1980  (November  1979  data),  and  July,  1980  (March  data). 

It  is  on  the  "output  side"  of  the  EDB  where  emphasis  on  the 
word  "experimental"  has  occurred.  Each  of  these  EDB  Output 
Reports  has  been  a major  revision  of  the  previous  report  in  terms 
of  both  format  and  content.  Methods  of  presenting  the  data, 
level  of  detail,  accuracy  and  validity,  statistical 
significance  ....  All  of  these,  and  more,  are  of  concern  to 
the  Liaison  Board  members,  and  their  concern  is  reflected  in  the 
high  level  of  interest  being  expressed  in  the  presentation  of 
information  from  the  EDB. 
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A Critical  Design  Review  (CDR)  of  TRIP  was  held  in  April 
1980.  The  CDR  Committee,  consisting  of  the  TRIP  Liaison  Board 
representatives  from  the  six  participating  properties  and 
representatives  from  APTA,  UMTA,  and  TSC,  reviewed  the  preceding 
24  months  of  TRIP  activity;  assessed  TRIP  benefits;  listened  to 
each  participant's  position  on  TRIP;  and  concluded  that  TRIP 
should  be  continued.  It  was  further  concluded  that  TRIP  cannot 
be  properly  evaluated  without  12  to  18  months  of  additional  EDB 
experience . 

The  CDR  recommendation  impacted  Phase  I of  the  TSC  TRIP 
Implementation  Plan  as  follows: 


• The  operation  and  refinement  of  the  RRV-EDB  by  DRC  with 
three  major  assemblies  from  6 series  of  vehicles  will  be 
continued  for  an  additional  21  months  (15-month  EDB 
operation  and  refinement  with  an  additional  6-month  EDB 
operation  and  merge  transition  period)  . 

• The  establishment  and  operation  by  TSC  of  an  EDB  for 
buses  will  begin  during  Phase  I by  monitoring  a sample  of 
assemblies  from  a limited  number  of  buses.  Participation 
and  interest  in,  as  well  as  potential  benefits  from  Phase 
I indicate  that  TRIP  EDB  users  (operating  properties, 
consultants.  Federal  Government,  and  suppliers)  want 
factual  information  from  TRIP  and  are  relying  on  TRIP'S 
large  quantity  of  readily  available  maintenance  data  to 
provide  timely  reports  of  equipxnent  replacement 
experience . 


Pending  a favorable  decision  from  the  final  Phase  I CDR, 
Phase  II  will  start  a full-scale  merged  RRV  and  Bus  TRIP  Data 
Bank.  It  will  be  established  and  put  on  line  starting  with  the 
transfer  of  data  from  the  RRV  and  Bus  EDB's.  The  number  of 
equipments  initially  monitored  will  be  small,  but  as  the 
capability  expands,  additional  equipments  will  be  monitored  until 
failure  data  on  all  vehicle  components  are  contained  in  the  data 
bank . 


A CDR  of  Phase  II  can  then  be  performed  to  determine  if 
Phase  II  accomplished  its  goals  and  if  Phase  III  is  justified. 
Phase  III  is  envisioned  as  the  expansion  of  the  Data  Bank  and 
GPL's  to  cover  UMTA  responsibilities  in  Fare  Collection,  ATO/ATC, 
and  track  and  structures.  As  other  transportation  equipments  are 
incorporated,  the  TRIP  Data  Bank  will  become  the  UMTA  National 
TRIP. 
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2.3  REFERENCES 


The  following  reports,  issued  by  the  Dynamics  Research 
Corporation  (DRC),  collectively  describe  the  development  of  the 
TRIP  Experimental  Data  Bank.  Except  for  references  (6)  and  (7), 
below,  these  are  "draft"  reports  which  document  the  progressive 
development  of  the  EDB.  In  some  cases,  the  specific  information 
contained  in  these  reports  has  become  obsolete.  For  the  most 
part,  however,  the  concepts  remained  valid  as  the  EDB  evolved  and 
have  been  incorporated  into  one  or  more  of  the  "final"  reports, 
references  (11)  through  (14),  below. 

(1)  Report  No.  E-4852U  - TRIP  Task  1 Draft  Report  (Data 

Bank/Source  Investigation),  December  18,  1978. 

(2)  Report  No.  E-4894U  - TRIP  Task  2 Draft  Report  "TRIP 

Data  Bank  Scope  and  Definition",  January  18,  1979. 

(3)  Report  No.  E-4895U  - TRIP  Task  3 Draft  Report  "Transit 
Vehicle  Equipment  Lists",  January  18,  1979. 

(4)  Report  No.  E-4896U  - TRIP  Task  3 Draft  Report 

"Reliability  Equipment  List  Operating  Procedures", 
January  18,  1979. 

(5)  Report  No.  E-4998U  - TRIP  Task  4 Interim  Report  "Rapid 
Rail  Transit  Vehicles  Guidelines  for  the  Operation  and 
Use  of  the  TRIP  Data  Bank",  April  16,  1979. 

(6)  Report  No.  R-284U  - "TRIP  Experimental  Data  Bank 

Acceptance  Test  Plan-Final",  July  9,  1979. 

(7)  Report  No.  R-285U  - "TRIP  Experimental  Data  Bank 

Acceptance  Test  Procedures-Final" , July  9,  1979. 

(8)  Report  No.  E-5234U  - "TRIP  Experimental  Data  Bank 

Program  Maintenance  Manual  - Preliminary",  October  19, 
1979. 

(9)  Report  NO.  E-5235U  - "TRIP  Experimental  Data  Bank 

User’s  Manual  - Draft",  October  19,  1979. 

(10)  Report  No.  E-5361U  - "TRIP  Generic  Maintenance  Action 
Codes",  February  5,  1980. 

The  following  reports,  also  issued  by  DRC,  are  companion 
documents  to  the  "TRIP  Phase  I Final  Report".  Collectively, 
these  reports  document  the  configuration,  operation,  use, 
applications,  and  development  of  the  TRIP  experimental  Data 
Bank . 

(11)  Report  No.  R-337U  - "TRIP  Experimental  Data  Bank 

Program  Maintenance  Manual",  September  1980. 
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(12)  Report  No.  R-338U  - "TRIP  Experimental  Data  Bank 

Operating  Procedures  Manual",  March  1981. 

(13)  Report  No.  R-339U  - "TRIP  Participants  Guidelines" 

September  1980. 

(14)  Report  No.  R-340U  - "TRIP  Reliability  Demonstration 
Plan  for  Rapid  Rail  Vehicles",  March  1981. 


3.  PHASE  I EVALUATION 


The  purpose  of  this  section  is  to  present  an  evaluation  of 
the  results  obtained  and  conclusions  reached  during  Phase  I of 
Contract  Number  DOT-TSC- 1 559 • Phase  I consisted  of  two  major 
activities,  covering  the  planning,  designing,  and  testing  of  a 
small  (experimental)  data  bank: 

• Define  and  document  TRIP  functional  and  operational 
requirements  necessary  to  satisfy  the  TRIP  Program 
requirements; 

• Develop,  establish,  and  operate  an  Experimental  Data  Bank 
(EDB)  as  a prototype  of  the  full-scale  TRIP  Data  Bank  for 
the  purpose  of  evaluating  the  proposed  methodology. 

This  evaluation  is  based  on  DRC's  close  monitoring  of  the 
complete  operation  of  the  EDB,  especially  critical  recognition  of 
operational  bottlenecks,  contradictory  procedures,  unanticipated 
situations,  and  costs  per  unit  input.  This  careful  scrutiny  has 
addressed  the  three  major  areas  of  TRIP: 

• TRIP  Data  Bank  Concept  - to  ensure  that  the  design  of  the 
system  is  responsive  to  the  stated  objectives  of  TRIP; 

• EDB  Operation  - to  ensure  that  TRIP: 

- is  a cost-effective  solution  to  satisfying  the 
reliability  information  requirements  of  the  transit 
industry ; 

provides  a maximum  amount  of  information  while 
imposing  a minimum  burden  upon  TRIP  users; 

• Transit  Industry  Feedback  - to  ensure  that  TRIP  is 
responsive  to  the  ultimate  end-users  of  the  Data  Bank. 

This  evaluation  o’f  the  TRIP  concept  and  Data  Bank 
configuration  and  operation  should  provide  an  accurate  appraisal 
of  the  potential  contribution  of  TRIP  to  improve  transit 
equipment  reliability. 


3.1  TRIP  CONCEPT  ASSESSMENT 


When  the  objectives  of  TRIP  were  stated  at  the  kick-off 
meeting  (November  8,  1978),  there  was  a high  degree  of  skepticism 
about  successfully  undertaking  such  a project.  It  was  expressed 
that  it  was  impossible  to  collect  data  from  a number  of 
independent  sources,  put  it  into  a common  data  bank  and  produce 
commonly  formatted  outputs. 
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One  and  one-half  years  later,  at  the  first  Critical  Design 
Review  of  TRIP,  the  skepticism  turned  to  statements  of  strong 
support  of  the  concept  and  recommendations  to  continue  the 
program  based  on  its  success  to  date.  Representatives  of  the  the 
six  rail  properties  that  are  participating  in  the  operation  of 
the  TRIP  Experimental  Data  Bank  (EDB)  expressed  their  favorable 
support  for  continuing  the  EDB  in  order  to  further  refine  the 
system . 

Even  though  the  long-term  benefits  were  not  apparent  at  that 
point  in  the  program  (and  will  not  be  apparent  until  some  unknown 
point  in  the  future) , the  participants  felt  that  the  foundation 
and  concepts  upon  which  TRIP  is  built  were  proven.  These 
"proven"  concepts  can  be  stated  as  follows: 

• Consolidate  transit  industry  reliability  efforts; 

• Provide  reliability  information  presented  in  a transit 
industry  context; 

• Provide  maximum  information  output  while  minimizing 
burden  on  data  sources; 

• Provide  a comprehensive  data  source  for: 

equipment  reliability  comparison; 
new  equipment  procurement; 
product  improvement  programs; 
system  analysis  efforts. 

Since  that  first  CDR,  when  it  became  apparent  that  TRIP 
concepts  have  been  proven  through  EDB  operation,  the  emphasis  has 
been  to  continually  refine  the  system  based  on  the  participants’ 
interface.  This  emphasis  has  covered  the  following  areas  of 
refinement: 

• EDB  Software  Enhancements,  including; 

additional  aids  for  hard-copy  data  entry; 
development  of  new  output  reports; 

• EDB  Data  Validation,  including; 

increased  input  and  output  auditing  capability; 
output  data  averaging  over  prescribed  intervals; 

• EDB  Expansion,  including; 

one  additional  property; 

one  additional  vehicle  system. 
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3.2  EXPERIMENTAL  DATA  BANK  ASSESSMENT 


The  Experimental  Data  Bank  (EDB)  is  a scaled-down  data  bank 
which  reflects  the  full-scale  system  as  nearly  as  possible.  The 
EDB  was  established  in  order  to  detect,  modify,  and  improve 
imperfections  in  the  operating  guidelines  before  the  full-scale 
system  goes  on-line.  The  experimental  aspects  of  data 
collection,  screening,  processing  and  reporting  are  being 
conducted  with  the  intention  of  upgrading  procedures  and 

periodically  conducting  reviews  of  the  system  (CDR’s). 

Significant  progress  was  made  in  Phase  I during  which  six 
rapid  rail  properties,  BART,  CTA,  GCRTA,  NYCTA,  PATCO,  and  WMATA, 
were  solicited  and  agreed  to  participate  in  the  TRIP  EDB.  Their 
participation  consisted  of  selecting  one  series  of  vehicles  from 
their  property  for  monitoring  by  the  EDB  and  having  a 

representative  of  their  property  on  the  APTA  TRIP  Liaison  Board. 
Members  met  to  review  and  make  recommendations  on  the 
establishment  of  Generic  Pars  Lists  (GPLs)  , the  Regional  TRIP 
familiarization  meetings,  EDB  implementation  status,  use  of  the 
TRIP  Data  Bank,  and  any  other  ongoing  TRIP  activities. 

The  TRIP  EDB,  currently  being  operated  by  DRC,  collects 
utilization,  repair,  and  maintenance  data  on  the  door,  friction 
brake,  and  propulsion  systems  of  13OO  rapid  rail  vehicles  at  five 
properties;  analyzes  the  data;  and  generates  reports.  The  EDB 
serves  as  an  intermediate  step  toward  the  efficient  development 
and  implementation  of  the  full-scale  TRIP  Data  Bank  in  Phase  II. 

Based  on  the  first  CDR  (March  31 » 1980),  it  was  concluded 
that  the  EDB  operation  should  be  continued  from  one  to  two  years 
in  order  to  properly  evaluate  TRIP.  This  additional  EDB 
experience  will  include  bringing  the  sixth  participating  property 
(GCRTA)  on-line,  and  adding  an  additional  vehicle  system  to  the 
three  systems  currently  monitored  by  the  EDB. 


3.3  FULL-SCALE  TRIP  DATA  BANK  PROJECTION 


Pending  a favorable  decision  from  the  final  Phase  I CDR, 
Phase  II  will  start  a full-scale  merged  RRV  and  Bus  TRIP  Data 
Bank.  It  will  be  established  and  put  on  line  starting  with  the 
transfer  of  data  from  the  RRV  and  Bus  EDBs . The  number  of 
equipments  initially  monitored  will  be  small,  but  as  the 
capability  expands,  additional  equipment  will  be  monitored  until 
failure  data  on  all  vehicle  components  are  contained  in  the  Data 
Bank.  A projection  of  the  number  of  vehicles  that  will  be 
monitored  by  the  Data  Bank  is  given  in  Table  3-1. 

Based  on  this  projection,  and  by  collecting  data  on  all 
systems  of  some  10,000  bus  and  rail  vehicles,  the  full-scale  TRIP 
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Table  3-1.  DATA  BANK  PROJECTED  GROWTH 
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Data  Bank  could  grow  at  an  annual  input  rate  of  1.6  million 
dynamic  data  records.  Table  3-2  shows  an  estimate  of  records 
input  and  processed,  based  on  the  number  of  monitored  vehicles 
shown  in  Table  3-1 , assuming  that  0.5  records/vehicle/day  are 
generated.  Considerations  for  handling  this  volume  of  data  are 
discussed  in  Section  4. 

An  estimate  of  the  personnel  required  to  operate  and 
maintain  the  full-scale  TRIP  Data  Bank  is  shown  in  Table  3-3. 
The  functions  to  be  performed  by  each  type  of  personnel  can  be 
described  as  follows: 

• Manager:  Oversee  every  aspect  of  the  TRIP  system. 

• Engineer: 

Perform  data  validation; 

Perform  comparative  reliability  assesment; 

Perform  "other"  engineering  analyses. 

• Programmer: 

Provide  software  support  directed  by  engineering 

personnel  and  operations  supervisors; 

Provide  support  for  special  data  requests. 

• Data  Entry:  Enter  data  submitted  to  TRIP  by 

participating  properties. 

• Output  Generation:  Generate  output  reports  to  be 

distributed  to  participating  properties; 

• Operations  Supervisor:  Oversee  entire  Data  Bank 

operation,  including; 

Data  Entry; 

Output  Generation; 

Engineering  Analysis; 

Programming  Support. 


3.4  CRITICAL  DESIGN  REVIEW  SUMMARY 


The  first  Critical  Design  Review  (CDR)  was  held  at  APTA 
Headquarters  in  Washington,  DC,  on  March  31 » 1980.  The  CDR 
committee,  consisting  of  the  TRIP  Liaison  Board  representatives 
from  the  six  participating  properties  and  representatives  from 
APTA,  UMTA,  and  TSC , reviewed  the  preceeding  24  months  of  TRIP 
activity;  assessed  TRIP  benefits;  listened  to  each  participant's 
position  on  TRIP;  and  concluded  that  TRIP  cannot  be  properly 
evaluated  without  12  to  24  months  of  additional  EDB  experience. 
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Table  3-2.  DATA  BANK  SIZE 
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(100  Characters  Per  Record,  Average) 


Table  3-3.  DATA  BANK  STAFFING  ESTIMATE 
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Generally,  the  results  of  the 
follows : 


CDR  can  be  summarized  as 


• National  Data  Bank  concept  proven  through  EDB  operation; 

• TRIP  has  been  demonstrated  as: 

Central  source  of  transit  information; 

Flexible  and  responsive  to  meeting  user  needs; 

Provides  maximum  information  at  minimum  cost  to  user; 

• Expansion  and  operation  of  full-scale  Data  Bank  requires; 

Knowledgeable  personnel; 

Dedicated  resources; 

Systematic  expansion  approach; 

Orderly  operation. 


Specific  comments  of  the  CDR  Committee  concerning  the 
near-term  future  of  TRIP  are  highlighted  below: 

• The  full  benefit  of  TRIP  has  yet  to  be  realized  --  the 
major  benefits  will  be  derived  from  long-term  operation 
of  the  Data  Bank; 

• Dynamics  Research  Corporation  (DRC)  should  continue  to 
operate  the  TRIP  Experimental  Data  Bank  for  an  additional 
year  in  order  to  allow  more  time  to: 

Explore  the  full  potential  of  the  system; 

Develop  additional  output  reports; 

Refine  system  operation; 

expand  the  prototype  system; 
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• The  establishment  and  operation  by  TSC  of  an  EDB  for 
buses  will  begin  during  Phase  I by  monitoring  a sample  of 
assemblies  from  a limited  number  of  buses. 
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^4.  FULL-SCALE  TRIP  DATA  BANK  CONSIDERATIONS 


The  primary  purpose  of  the  TRIP  Data  Bank  is  to  provide  a 
system  for  the  collection,  analysis,  and  reporting  of  reliability 
information  on  transit  systems  and  equipment  on  a nationwide 
basis.  In  order  to  serve  this  purpose,  TRIP  Data  Bank 
development  has  focused  on  the  following  objectives: 

• Consolidate  transit  industry  reliability  efforts; 

• Provide  reliability  information  in  a transit  industry 
context ; 

• Provide  maximum  information  output  while  minimizing  the 
burden  on  data  sources; 

• Provide  a comprehensive  data  source  for: 

Equipment  reliability  comparison; 

New  equipment  procurement; 

Product  improvement  programs; 

System  analysis  efforts. 

The  purpose  of  this  section  is  to  provide  a summary  of 
characteristics  and  requirements  which  must  be  considered  in  the 
design,  implementation,  and  operation  of  a full-scale  TRIP  Data 
Bank.  This  section  is  based  upon  the  experience  gained  through 
the  design,  implementation,  and  operation  of  the  TRIP 
Experimental  Data  Bank  and  the  continuous  dialog  that  has  been 
maintained  between  DRC  and  representatives  of  the  operating 
transit  properties  who  have  actively  participated  in  the  program 
both  as  sources  of  input  data  for  the  EDB  and  members  of  the  TRIP 
Liaison  Board. 


4.1  GENERAL  CONSIDERATIONS 


The  subject  of  the  TRIP  Data  Bank  is  transit  equipment  and 
systems.  The  purpose  of  TRIP  is  to  collect,  analyze,  and  report 
reliability  information  on  this  equipxnent.  The  TRIP  Data  Bank  is 
therefore,  primarily  an  engineering  data  bank  and  should  be 
organized  as  such,  with  emphasis  upon  the  equipment  which  it 
monitors. 


4.1.1  Expansion  Capability 


Although  the  emphasis 
vehicles,  the  number  and 
TRIP  will  rapidly,  at  first 


to  date  has  been  on  rapid  rail 
types  of  equipment  to  be  monitored  by 
and  continuously  increase.  The  TRIP 
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Data  Bank  must,  therefore,  be  capable  of  rapid,  yet  orderly 
expansion . 


M . 1 . 2 Data  Types 


Two  basic  types  of  data  must  be  collected  by  TRIP:  "dynamic 
data",  or  data  which  is  continuously  produced  as  the  result  of 
operating  and  maintaining  the  equipment;  and  "static  data",  or 
reference  data  which  describes  the  attributes  and  operating 
environment  of  the  equipxnent.  Reliability  statistics  are 
generated  from  the  dynamic  data,  whereas  the  static  (reference) 
data  is  used  to  interpret  the  reliability  statistics.  Static 
data  is  entered  only  once  and  changes  infrequently.  Dynamic 
data,  on  the  other  hand,  is  added  continuously  to  the  data  base 
and  constitutes  the  bulk  of  the  data  that  is  stored  and 
processed . 


4.1.3  Record  Formats 


The  two  basic  types  of  data  can  be  subdivided  into  specific 
kinds  of  data.  Dynamic  data,  for  example,  includes  utilization 
data,  scheduled  maintenance  (inspection  and  preventative 
maintenance)  data,  and  unscheduled  maintenance  (repair)  data. 
Static  data  includes  such  subcategories  as  operating  environment 
data,  configuration  data,  and  specification  data. 

Separate  data  base  record  formats  should  be  provided  to 
address  the  specific  type  of  data  to  be  stored.  Data  storage  and 
retrieval  efficiency  can  be  maximized  if  each  type  of  record  can 
be  readily  identified  in  the  data  base.  The  number  of  record 

formats  should  be  limited,  however,  to  prevent  the  data  base  from 
becoming  an  organizational  maze. 


4.1.4  Data  Volume 


By  collecting  data  on  only  three  (of  eleven)  systems  on 
fewer  than  13OO  rapid  rail  vehicles,  the  EDB  is  growing  at  an 
average  annual  rate  of  72,000  records  (dynamic  data  only).  By 
collecting  data  on  all  systems  of  some  10,000  bus  and  rail 
vehicles,  the  full-scale  TRIP  Data  Bank  could  grow  at  an 
estimated  annual  rate  of  1.6  million  dynamic  data  records  (see 
Section  3-3).  The  TRIP  Data  Bank,  therefore,  must  be  capable  of 
high-volume  data  processing.  On-line  data  storage  should  be 
limited  to  a finite  calendar  period,  such  as  one  year,  in  order 
to  minimize  storage  costs. 
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4.1.5  Output  Reporting 


Routine  periodic  reports  should  be  published  at  least 
quarterly.  These  reports  should  contain  both  high-level 
summaries  stressing  graphics  to  provide  easy  industry  comparison, 
and  detailed  reports  for  the  data  sources  on  their  own 
equipment.  Trend  analysis  should  be  an  integral  part  of  routine 
reports . 

The  TRIP  Data  Bank  must  also  have  the  capability  to  respond 
to  requests  for  special  analyses  and  reports.  This  capability 
requires  engineering  access  to  the  data  base.  Special  request 
reports  will  probably  become  the  dominant  output  requirement  for 
the  TRIP  Data  Bank.  The  organization  and  staffing  of  the  Data 
Bank  should  be  oriented  toward  a demand  for  engineering  support 
from  the  industry. 


4.2  OPERATING  CONSIDERATIONS 


The  TRIP  Data  Bank  must  be  capable  of  accepting  data  from 
participating  transit  properties  in  its  organic  format.  This 
requires  that  the  TRIP  Data  Bank  must  be  highly  flexible  in  its 
ability  to  assimilate  data. 

The  data  input  subsystem  should  be  capable  of  accepting  data 
from  both  computer-readable  (e.g.,  magnetic  tape)  and  hard-copy 
media.  The  initial  stages  of  input  processing  require  customized 
software  and  algorithms  to  address  the  specific  attributes  of  the 
data  being  supplied.  Standard  formatting,  however,  should  be 
achieved  at  the  earliest  possible  point  in  the  input  software 
subsystem  to  minimize  the  number  and  size  of  custom  software 
modules . 

Because  of  the  varied  types  and  formats  of  data  to  be  stored 
in  the  TRIP  Data  Bank,  a "dictionary-driven"  software  system 
should  be  given  preferential  consideration.  A data  base 
dictionary  would  provide  single-point  definition  and  control  for 
all  data  base  update  and  data  access  functions.  New  record  types 
could  be  easily  introduced  by  modifying  only  the  dictionary 
without  the  necessity  of  extensive  software  modifications. 

The  safety  and  safeguarding  of  data  files  within  the  TRIP 
Data  Bank  should  be  included  as  routine  procedures.  Software 
design  should  incorporate  procedures  for  recovery  from  system  or 
software  failure.  Input  data  modules  should  be  protected  for 
restart  in  the  event  of  system  failure.  Automated  back-up  to 
tape  of  the  TRIP  Data  Base  should  be  included  as  a routine 
procedure  following  a data  base  update.  Input  data  files  used  in 
data  base  update  should  likewise  be  protected  to  prevent  the  loss 
of  data  due  to  system  failure. 
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4.2.1  Data  Submission 


Transit  properties  follow  their  own  independent  schedules 
for  data  submission.  Although  some  semblance  of  regularity  is 
achieved,  it  can  be  generally  expected  that  data  will  arrive 
"when  it  gets  there  and  not  any  sooner".  For  this  reason,  data 
submissions  must  be  carefully  monitored  and  catalogued  to  ensure 
that  output  reports  can  be  produced  in  a timely  manner  and  that 
data  is  not  lost.  At  NYCTA,  for  example,  the  computer  file  from 
which  utilization  data  is  derived  contains  62  days  (2  months)  of 
cumulative  mileage  for  each  vehicle.  The  daily  mileage  "cells" 
in  this  file  are  overwritten  at  the  end  of  each  day.  Therefore, 
no  more  than  six  weeks  should  be  allowed  to  pass  beyond  the  end 
of  a month  before  contacting  NYCTA  and  inquiring  about  a "late" 
data  tape. 

In  general,  data  can  be  expected  to  arrive  at  the  TRIP  Data 
Bank  facility  2-4  weeks  following  the  close  of  the  period  being 
reported.  For  properties  which  submit  data  (magnetic  tape  or 
hard-copy)  on  a monthly  or  4-week  cycle,  3-4  weeks  has  been  the 
average  delay  experienced  by  the  Experimental  Data  Bank.  A 2 - 3 
week  delay  has  been  typical  for  weekly  or  biweekly  submission  of 
hard-copy  data. 

Properties  submitting  hard-copy  data  should  be  encouraged  to 
submit  expendable  (from  their  perspective)  copies  of  the  data 
since  they  will  be  retained  by  the  Data  Bank.  If  non-expendable 
copies  are  submitted,  the  Data  Bank  must  provide  the  xerographic 
service.  Similarly,  data  submitted  on  magnetic  tapes  should  be 
transcribed  onto  Data  Bank  tapes  so  that  the  original  can  be 
returned  to  the  source  for  recycling  thus  minimizing  the  cost  of 
participation  to  the  property. 


4.2.2  Input  Data  Preparation  & Processing 


TRIP  Data  Bank  personnel  must  become  intimately  familiar 
with  the  format  and  content  of  the  data  being  submitted  by  each 
source.  A thorough  understanding  of  the  coding  schemes  used  to 
identify  the  equipment  itself,  the  equipment  condition  or 
disposition,  and  maintenance  actions  performed  on  the  equipment 
is  required  in  order  to  properly  design  the  algorithms  and 
software  necessary  to  convert  the  property’s  data  into  the 
standard  Data  Bank  format. 

The  operations  staff  must  also  be  knowledgeable  of  code 
definitions  and  usage  at  the  property  to  be  able  to  resolve 
anomalies  encountered  during  the  input  processing  of  the  data. 
Familiarity  with  the  equipment  for  which  the  data  is  being 
reported  and  the  vocabulary  used  by  the  property  to  describe  both 
the  equipment  and  the  maintenance  performed  on  it  is  necessary  in 
order  to  resolve,  from  narrative,  data  errors  which  have  been 
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in  the  encoding  and/or  entry  of  the  data. 

Some  data  errors  simply  cannot  be  resolved  by  reading  the 
narrative  data  or  referring  to  code  books.  It  is  important, 
therefore,  that  a liaison  be  maintained  between  the  TRIP  Data 
Bank  staff  and  the  transit  property  personnel. 

Data  errors,  regardless  of  the  source,  will  be  encountered. 
The  TRIP  Data  Bank,  therefore,  must  have  the  capability  to  deal 
with  these  errors  both  procedurally  and  operationally.  The  Data 
Bank  software  must  include  "error  files"  to  hold  data  which  fails 
input  editing,  "error  correction"  programs  for  accessing  and 
correcting  erroneous  data  records,  and  "automatic  retry"  of 
corrected  records  by  the  input  software. 


4.2.3  Data  Organization  & Storage 


As  previously  stated,  the  TRIP  Data  Bank  is  primarily  an 
engineering  data  bank  whose  function  is  to  collect,  store,  and 

analyze  data  on  transit  equipment  and  systems  for  the  purpose  of 
reporting  reliability  information.  Although  data  is  submitted  to 
TRIP  by  individual  transit  properties,  the  primary  objective  of 
the  TRIP  Data  Bank  is  not  to  report  that  data  back  to  the 

source.  Rather,  the  objective  of  TRIP  is  to  gather  data  on 
functionally  equivalent  components  from  many  sources,  analyze 
that  data,  and  report  back  to  the  industry  the  comparative 
reliability  achieved  or  experienced. 

The  organization  of  the  data  within  the  data  base  will  have 
the  greatest  impact  on  the  ease  with  which  data  can  be 

retrieved.  Having  too  few  major  "keys"  by  which  data  is  stored 
results  in  too  large  a block  of  data  being  retrieved  for  a 
particular  set  of  search  criteria.  Having  too  many  "keys" 
results  in  excessive  retrieval  costs  because  each  key  must  be 
searched  and  tested  for  a proper  match  with  the  specified 
criteria . 

Data  records  should  consist  of  two  "parts",  label  and  data, 
for  ease  of  access.  The  record  label  should  have  at  least  the 
following  key  fields: 

• Part  Number  --  to  identify  the  component  to  which  the 
record  pertains; 

• Source/Location  --  the  transit  property  and  car  (or 
coach)  number  in  which  the  component  is  in  service; 

• Record  Type  --  to  identify  the  type  of  data  contained 
in  the  record  (e.g.,  repair,  inspection,  mileage, 
specification,  etc.); 
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• Date  --  the  origin  date  of  the  record  (e.g.,  date  of 
inspection  or  repair  completion,  date  on  which  mileage 
was  recorded;  etc.); 

• Subdate  --  an  index  number  to  differentiate  between 
multiple  records  for  the  same  label,  but  different  data. 


4.2.4  Data  Retrieval  & Analysis 


The  TRIP  Data  Bank  should  include  the  capability  to  access 
any  data  element  within  a record  and,  on  the  basis  of  that  data 
element,  retrieve  the  record  either  wholly  or  in  part.  The 
primary  method  of  data  access  and  retrieval,  however,  should  be 
via  the  "key  label"  of  a (two-part)  data  base  record,  as 
described  in  the  preceeding  subsection. 

"Bulk"  data  extraction  via  the  record  key  is  an  efficient 
method  of  subsetting  the  data  contained  in  a large  data  base. 
Routine  report  production,  for  example,  requires  only  a 

three-month  subset  of  the  data  base  to  produce  a "monthly" 
report.  Subsetting  of  the  data  base,  therefore,  can  be 
accomplished  via  the  "Date"  key  field. 

Search,  sort,  and  other  statistical  and  analytical  routines 
also  operate  more  efficiently  if  the  number  of  the  data  elements 
being  processed  is  kept  reasonably  small.  Two-stage  data 
retrieval  - "bulk"  subset;  then  detailed  search  - has  been 
successfully  employed  in  the  Experimental  Data  Bank  and  has 
proven  to  be  the  most  cost-effective  method  of  accessing  data. 

The  TRIP  Data  Bank  must  be  capable  of  performing  trend 
analysis  as  well  as  incremental  (i.e.,  monthly)  analysis.  To 
eliminate  the  necessity  of  reprocessing  monthly  segments  of  data, 
the  monthly  statistics  should  be  stored  in  summary  form  for  use 
in  performing  trend  analyses.  The  summary  statistics  should  span 
a minimum  of  thirteen  (13)  months  in  order  to  display  seasonal 
fluctuations . 


4.2.5  Data  Reporting 


The  major  consideration  for  the  reporting  of  data  from  the 
TRIP  Data  Bank  is  that  the  information  reported  must  accurately 
represent  the  data  provided  as  input  by  the  properties.  The 
accurate  processing  of  data  from  input  through  to  output  is  an 
absolute  requirement  of  the  TRIP  Data  Bank. 

Beyond  accuracy,  however,  is  the  requirement  that  the 
information  presented  in  the  output  reports  of  the  TRIP  Data  Bank 
be  valid.  Intermediate  processing  of  data  for  validity  should  be 


26 


integrated  into  all  subsystems  and  modules  of  the  TRIP  Data  Bank 
software.  The  validity,  or  "reasonableness",  of  the  data, 
however,  requires  more  than  just  automated  data  processing  to 
ascertain.  The  TRIP  Data  Bank  personnel  should  possess 
familiarity  with  the  vehicles  and  equipment,  transit  properties, 
and  industry  which  TRIP  has  been  designed  to  support. 


4.3  FUNCTIONAL  CONSIDERATIONS 


Functional  requirements  of  the  TRIP  Data  Bank  (TDB)  are 
shown  in  Figure  4.1.  From  a practical  perspective,  the  objective 
of  the  TDB  is  to  produce  information  in  the  form  of  periodic  and 

special  output  reports.  The  data  from  which  this  information  is 

derived  is  generated  within  the  operation  and  maintenance 
environments  of  transit  authorities. 

Output  reports  are  generally  limited  in  number,  type,  and 
format;  yet  the  variety  and  content  of  input  data  formats  is 
limited  only  by  the  number  of  transit  authorities  that  are 
supplying  the  data.  It  is  incumbent  upon  the  Data  Bank, 
therefore,  to  provide  the  following  functional  capabilities: 

• STANDARD  FORMATTING  — to  prepare  and  transform  the 

otherwise  diverse  data  into  a format  which  can  be 

processed  by  "standard"  software  using  "standard" 
techniques  and  algorithms; 

• DATA  EDITING  AND  VERIFICATION  — to  ensure  the  accuracy 
and  validity  of  the  data  being  processed  for  Data  Bank 
input ; 

• DATA  ORGANIZATION  AND  STORAGE  — to  provide  maximum 
retrieval  efficiency  of  voluminous  data; 

• DATA  RETRIEVAL  AND  REPORTING  --  to  provide  for  the 
production  of  routine  reports,  reference  information 
reports,  and  special  reports  necessary  for  assisting  and 
supporting  the  activities  and  needs  of  TRIP  users. 


4.3.1  Data  Submission 


A liaison  must  be  established  and  maintained  between  the 
TRIP  Data  Bank  and  each  participating  transit  property. 
Preferably,  all  communications  with  a transit  property  are 
channeled  through  a single  individual  at  the  property.  Multiple 
paths  of  communication,  which  can  lead  to  duplication  of  effort, 
should  be  avoided. 

All  inquiries  regarding  "late"  data  submissions  and  data 
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Figure  4-1  TRIP  DATA  BANK  FUNCTIONAL  REQUIREMENTS 


anomalies  should  be  directed  to  this  individual.  The  property 
should  be  encouraged  to  appoint  someone  to  this  position  who  is 
knowledgeable  of  the  data  being  submitted  to  TRIP.  The  liaison 
should  be  familiar  (or,  at  least,  know  who  to  ask  at  the 
property)  with  the  vehicles  and  equipment  being  monitored  by 
TRIP,  its  operation  and  maintenance,  and  the  generation,  flow, 
and  use  of  data  at  the  property. 


Data  submission  also  involves  obvious  logistics 
considerations.  The  receiving  of  incoming  data  and  shipping  of 
processed  tapes  are  routine  functions  of  TRIP  Data  Bank 
operation.  All  receipts  and  shipments  must  be  monitored  and 
catalogued  to  ensure  that  no  data  is  lost. 


4 . 3 • 2 Input  Data  Preparation  & Processing 


The  various  transit  authorities  employ  different  methods  of 
collecting  and  processing  the  data  that  they  may  generate  during 
the  course  of  operating  and  maintaining  their  equipment.  In 
order  to  accommodate  this  diverse  data  in  the  TRIP  Data  Bank,  the 
design  of  the  Data  Bank  software  must  include  functional  modules 
for  converting  the  incoming  data  from  the  unique, 
property-specific  format  to  the  standard  format  of  the  Data 
Bank.  These  functions  include: 

• HARD-COPY  DATA  ENTRY  --  direct  entry  of  data  through  a 
video  display  computer  terminal  from  hard-copy  form; 

• MAGNETIC  TAPE  DATA  EXTRACTION  --  selection  of 
TRIP-related  data  from  computer-generated  magnetic  tapes 
of  transit  property  data; 

• STANDARD  (GENERIC)  DATA  FORMATTING  --  conversion  of  the 
data  record  from  the  transit  property  format  into  the 
standard  TRIP  Data  Base  input  record  format; 

• GENERIC  MAPPING  --  cross-referencing  of  selected  data 
elements  to  standardized  (generic)  equivalents; 

• DATA  EDITING  --  comparison  of  data  elements  with 
property-specific  definitions,  value  ranges,  etc.; 

• ERROR  CORRECTION  --  determining  and  implementing 
corrections  to  data  elements  which  failed  data  editing. 

Data  editing  should  be  integrated  into  all  functional 
elements  of  input  data  preparation  and  processing.  "Editing" 
includes  checking  both  content  (values  versus  definitions)  and 
syntax  (position,  number  of  characters,  alpha  versus  numeric 
characters,  etc.).  "Range  testing"  is  a typical  editing 
technique  applied  to  content  for  screening  data. 
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Another  form  of  editing  is  the  automated  validation  of 
selected  data  elements  of  the  input  data  records.  The  "generic 
mapping"  function  (see  4. 3-2. 2,  below)  is  by  its  nature  the  major 
form  of  data  validation.  Data  cross-referencing  from 
property-specific  values  to  generic  (standard)  values  is  most 
easily  accomplished  via  table  look-up  routines.  In  order  for  a 
data  element  to  be  "mapped",  the  property  value  must  appear 
literally  in  the  cross-reference  table. 

The  table  look-up  approach  to  date  validation  could  be 
applied  to: 

• Cross-referencing  of: 

Property  acronym  (or  name)  to  a numeric  code; 

Property  part  numbers  to  "generic"  part  numbers; 

Property  maintenance  codes  to  "generic"  maintenance 

codes ; 

• Vehicle  (i.e.,  car/coach  body)  number  appearance  on  the 
property  roster. 

Automated  data  validation  may  also  be  applied  to  the 
combination  of  certain  data  elements  such  as  part  numbers  versus 
maintenance  codes.  For  example,  a "defect"  code  defined  as 
"wheel  flat  - 2-inch"  can  apply  only  to  the  steel  wheels  of  a 
transit  car. 

The  ability  to  correct  data  errors  must  be  provided  along 
with  the  ability  to  detect  them.  Records  containing  errors 
should  be  corrected  prior  to  entry  onto  the  Data  Base.  Error 
correction  requires  the  following,  as  a minimum: 

• Error  detection  and  identification; 

• Manual  correction  determination  (e.g.,  substitutionary 

data),  including  transit  property  interface  (if 

required) ; 

• Manual  correction  implementation: 

Accessing  the  "bad"  data  record;  and 

Substituting  the  "correct"  data  for  the  "bad"  data 

element;  or 

Deleting  the  entire  "bad"  record,  if  appropriate; 

• Automatic  "retry"  of  corrected  records. 

Standard  formatting  is  a two-stage  process.  The  first  step 
is  to  convert  the  data  from  the  property  format  to  a standard, 
intermediate  format.  This  function  should  be  accomplished  by  the 
data  entry/ ex tr act ion  software  (see  4.3*2. 1,  below)  so  that 
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"standard"  software  can  be  used  for  all  other  Data  Bank 
functions.  The  second  step  is  to  cross-reference  selected  data 
elements  of  the  standardized  property  data  record  to  "generic" 
values,  append  these  values  to  the  property  data,  and  reformat 
the  data  elements  into  the  standard,  generic  record  format  (see 
4. 3.2. 2,  below)  for  subsequent  entry  onto  the  TRIP  Data  Base  (see 
4.3.3)  . 


4 . 3 . 2 . 1 Data  Entry 


The  data  received  from  the  transit  properties  generally  does 
not  contain  any  reference  to  the  transit  property  except  for  the 
return  address  on  the  package.  The  property  ID,  therefore,  must 
be  added  to  the  data  records  during  the  data  entry  process. 

The  major  objective  of  the  data  entry  function  is  to  convert 
the  property-specific  data  into  a standard  format  for  subsequent 
processing  by  standard  software.  The  TRIP  Data  Bank  must  be 
capable  of  accepting  data  from  both  hard-copy  forms  and 
computer-readable  media  (e.g.,  magnetic  tapes). 

For  hard-copy  data,  procedures  must  be  established  for  the 
handling,  sorting,  processing,  and  archival  storage  of  the  data 
forms.  Hard-copy  data  entry  should  be  via  video  display 
terminals  driven  by  interactive  software.  Although  this  software 
may  reside  on  the  Data  Bank  host  computer,  off-line  data  entry  is 
preferred  since  "intelligent  terminals"  and/or  "desk  top 
computers"  provide  both  lower  per-record  input  costs  and  easily 
expandable,  multi-station  data  entry  capability.  Tape  cassettes 
of  diskettes  could  be  used  as  the  off-line  bulk  storage  media. 
The  data  from  the  cassetts  or  diskettes  can  then  be  batch-loaded 
into  the  host  computer  for  the  next  stage  in  input  processing. 

Hard-copy  data  entry  software  should  include  the  following 
functional  capabilities: 

• Direct  data  entry  (no  keypunching); 

• Multiple  screen  formats  for  data  input  including 
"look-alike"  formats  for  each  source  and  type  of 
hard-copy  data; 

• "Menu"  selection  of  screen  formats  to  accomodate  the 
addition  of  new  formats  as  required; 

• Automatic  fill-in  of  repetitive  data  elements  (e.g., 
date,  property  acronym,  etc.); 

• Immediate  syntax  checking  (e.g.,  required  data  elements, 
numeric  versus  alphabetic  characters,  etc.); 

• Data  element  reformatting/reordering. 


31 


The  input  processing  of  computer-readable  data  is  similar  to 
that  of  hard-copy  data  except  that  the  human  factor  is  replaced 
by  automated  algorithms.  Magnetic  tape  data  entry  requires 
’’customized"  software  for  each  transit  property  due  to  the  unique 
format  and  content  of  the  tapes  from  each  source.  Some  tapes  may 
be  directly  readable  by  the  Data  Bank  host  computer.  Other 
tapes,  however,  may  require  code  set  and/or  format  conversion 
before  the  logical  processing  of  the  data  can  be  performed. 

Magnetic  tape  data  extraction  programs  may  require  any  or 
all  of  the  following  functional  capabilities: 

• Record  sorting,  screening,  and  selection  based  upon  one 
or  more  data  elements  (e.g.,  part  number,  record  type, 
etc . ) ; 

• Record  merging  (e.g.,  when  the  data  pertaining  to  a 
single  maintenance  event  is  distributed  among  multiple 
records) ; 

• Data  element  extraction  and  reordering; 

• Date  record  formatting  into  multiple  standard  record 
types ; 

• Processing  "restart"  in  the  event  of  output  file 
overflow . 


4. 3. 2. 2 Generic  Mapping 

The  purpose  of  the  "generic  mapping"  function  is  to 
cross-reference  selected  data  elements  of  the  property  input 
record  to  equivalent  generic  (common)  values.  Generic  data 
elements  form  the  basis  for  comparative  reliability  assessment 
and  data  reporting.  Part  numbers,  maintenance  codes  (repair  or 
test),  and  equipment  condition  codes  (symptom  or  defect)  should 
be  cross-referenced  to  a common  (generic) set  of  codes  based  upon 
equivalent  definitions.  Generic  codes  should  be  appended  to  the 
property  data  during  the  input  processing  of  data  and  stored  as 
an  integral  part  of  the  data  record. 

The  generic  mapping  process  could  be  accomplished  by  a 
series  of  table  look-up  routines.  The  first  step  would  be  to 
construct  a "Generic  Serial  Number"  (GSN)  for  the  data  record  to 
identify  the  source  of  the  data  (i.e.,  the  transit  property), 
vehicle  number  to  which  the  data  pertains,  and  the  vehicle  series 
to  which  the  vehicle  belongs.  The  vehicle  number  contained  in 
the  data  record  can  be  used  as  a search  key  to  determine  the 
vehicle  series  from  "Fleet  Tables"  which  are  identified  by 
property  ID. 

The  next  step  in  the  generic  mapping  process  would  be  to 
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cross-reference  the  transit  property  part  number  contained  in  the 
data  to  a "Generic  Part  Number"  (GPN) . A table  of  transit 
property  part  numbers  versus  GPNs  should  be  prepared  for  each 
type  or  series  of  vehicles  for  which  the  transit  property  is 
submitting  data.  A vehicle  series  is  defined  as  a grouping  of 
vehicles  based  upon  the  following: 

• Single  or  multiple-unit  (e.g.,  married  pairs)  vehicles 
purchased  under  a specific  contract  (e.g.,  NYCTA's  R-44 
cars) ; 

• Single  vehicles  whose  configuration  differs  from  another 
"type"  of  vehicle  purchased  under  the  same  contract 
(e.g.,  BART'S  "A"  versus  "B"  cars); 

• Both  of  the  above  (e.g.,  PATCO's  single  cars  versus  their 
older  married  pairs) . 

Each  table  of  part  numbers  should  be  compiled  into  a 
"Generic  Parts  List"  (GPL)  . Since  each  type  or  series  of  vehicle 
is  unique,  a separate  GPL  should  be  prepared  for  each  vehicle 
series  and  contain  the  property  part  numbers  and  corresponding 
GPNs  which  pertain  to  that  vehicle  type.'  Each  GPL  should  be 
identified  by  property  ID  and  vehicle  series  ID.  The  generic 
mapping  of  the  property  part  number  contained  in  the  data  record 
can  be  accomplished  by  using  the  property  ID  and  vehicle  series 
ID  elements  of  the  GSN  created  in  the  first  step  of  the  generic 
mapping  process  to  select  the  appropriate  GPL,  and  then  using  the 
property  part  number  from  the  data  record  to  search  the  GPL  for 
the  corresponding  GPN. 

The  final  step  in  the  generic  mapping  process  is  to 
cross-reference  the  transit  property  maintenance  action  codes  to 
Generic  Maintenance  Action  Codes.  Maintenance  action  codes 
describe  the  four  basic  steps  in  the  maintenance  process: 

• SYMPTOM  CODES  --  describe  operational  problems  usually 
experienced  by  the  vehicle  operator; 

• DEFECT  CODES  — describe  reasons  behind  the  observed 
symptom  which  are  usually  discovered  during 
trouble-shooting,  inspection,  testing,  or  maintenance 
activities; 

• REPAIR  CODES  --  describe  actions  taken  to  correct  known 
defects  or  to  treat  observed  symptoms; 

• TEST  CODES  --  describe  actions  taken  to  disclose  a 
defect  or  to  validate  a repair. 

A Maintenance  Code  Table  is  a cross-reference  table  of 
transit  property  maintenance  action  codes  versus  Generic 
Maintenance  Action  Codes.  A Codes  Table  should  be  prepared  for 
each  property  that  is  supplying  data  to  the  Data  Bank.  The 
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property  ID  element  of  the  GSN  should  be  used  to  identify  and 
select  the  appropriate  Maintenance  Codes  Table.  The  transit 
property  maintenance  action  codes  from  the  data  record  can  then 
be  used  to  search  the  Codes  Table  for  the  corresponding  generic 
codes . 

If  the  table  look-up  routines  are  successful  in  assigning 
generic  values,  the  record  is  reformatted  into  a "generic 
transaction"  which  combines  the  data  elements  of  the  property 
record,  or  "non-generic  transaction",  with  the  generic  values. 
If  the  mapping  process  fails  a table  look-up  routine  (e.g.,  car 
number,  property  part  number,  or  property  maintenance  code  cannot 
be  found  on  the  table)  , the  entire  "non-generic  transaction" 
should  be  written  to  an  error  file  for  examination  and  correction 
by  the  operations  personnel.  The  TRIP  Data  Bank  must  include 
software  for  correcting  these  records  so  that  they  can  be 
re-processed  during  the  next  execution  of  the  generic  mapping 
function . 

After  an  entire  "batch"  of  new  and  corrected  records  have 
been  mapped  and  reformatted  into  "generic  transactions" 
consisting  of  key  fields  (GPN,  GSN,  date  (from  the  data  record), 
subdate,  and  record  type)  and  data  fields  (property  and  generic 
data  elements),  the  records  should  be  sorted, 

character-by-character,  into  a working  file.  Each  record  should 
be  compared  with  the  next  record  in  the  sorted  sequence.  If  two 
or  more  records  are  exact  duplicates,  the  first  record  should  be 
retained  and  the  duplicate  records  "dropped".  Such  duplications 
should  be  treated  as  multiple  submissions  by  the  property; 
therefore,  only  the  first  submission  is  to  be  retained  as  valid 
data . 


If  the  key  fields  of  two  or  more  records  are  duplicate,  yet 
the  succeeding  data  fields  differ  by  at  least  one  field,  the 
subdate  key  field  should  be  incremented  by  one  (i.e.,  reset  from 
"0"  to  "1",  "2",  etc.)  to  establish  a unique  "key  label"  for  each 
data  record.  After  all  records  have  been  processed  from  the 
sorted  work  file,  they  should  be  written  to  tape  for  subsequent 
input  to  the  data  base.  This  off-line  media  for  data  storage 
serves  as  the  input  media  for  the  data  base  management  software 
and  provides  the  ability  for  restart  if  a system  or  software 
failure  occurs  during  data  base  update. 

It  should  be  noted  that  primary  control  for  the  generic 
mapping  process  is  derived  from  the  various  cross-reference  files 
that  are  used  in  the  table  look-up  routines.  Once  established, 
the  contents  of  these  files  are  reletively  stable.  Some  changes 
do  occur,  however,  as  vehicles  are  retired  from  service  due  to 
accident  or  vandalism,  maintenance  codes  are  redefined,  or  new 
equipment  is  introduced.  The  TRIP  Data  Bank  software,  therefore, 
must  include  programs  for  maintaining  the  cross-reference  tables. 
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4.3.2. 3 Data  Organization  & Storage 


The  TRIP  Data  Bank  must  be  capable  of  accepting  a wide 
variety  of  data  on  the  operation,  maintenance,  specification, 
configuration,  and  operating  environment  of  transit  equipment  and 
systems.  The  organization  of  this  data  in  the  data  base  will 
have  major  effects  on  the  operation  of  the  TRIP  Data  Bank, 
including:  efficiency  of  adding  to  and  updating  the  information 

contained  in  the  data  base;  expediency  of  producing  routine 
reports  and  outputs;  flexibility  of  data  retrieval  to  produce 
special  reports  and  analyses;  and  cost  of  operation. 

A number  of  possible  data  bank  storage  formats  could  be 
utilized  for  TRIP.  One  would  be  a sequential  chronological 
format  based  on  the  order  in  which  the  data  is  received.  Another 
would  provide  for  storage  of  input  data  in  multiple  locations  or 
files  based  upon  the  types  of  retrievals  which  may  be  required. 
Sequential  data  storage  would  provide  a simple  format  for  data 
input  by  the  addition  of  new  data  to  the  last  data  previously 
stored.  Sequential  storage,  however,  would  require 

time-consuming  searches  of  stored  data  to  locate  each  data  item 
required  for  routine  or  special  outputs.  Multiple  storage 
locations  would  be  advantageous  for  routine  data  retrieval  by 
having  data  already  collected  and  organized  for  these  outputs. 
Multiple  storage,  however,  would  require  more  time  to  input  data 
to  the  several  locations  and  more  space  to  store  it  in.  Lengthy 
retrieval  searches  would  also  be  required  to  produce  special 
outputs  since  the  data  would  have  to  be  reassembled  from  its 
various  locations. 

A third,  and  more  efficient,  data  base  storage  concept, 
which  provides  both  flexibility  of  data  retrieval  and  efficient 
use  of  storage  space,  is  an  "integrated  data  base".  The 
characteristics  of  this  storage  approach  include: 

• Storage  of  all  data  in  one  central  location,  thereby 
permitting  efficient  access  to  any  data  element  or  groups 
of  elements; 

• Entry/ storage  of  each  unique  data  element  once  and  only 
once  to  minimize  storage  space  requirements; 

• Organization  of  all  data  types  based  upon  the  logical 
relation  of  "index  keys"  assigned  to  data  records; 

• Storage  of  different  types  of  data  based  upon  the  same 
"index  key"  arrangement  to  maximize  retrieval  efficiency. 

The  use  of  an  "intregrated  data  base"  organizational 
approach  for  the  TRIP  Data  Bank  could  utilize  the  Generic  Part 
Number  as  the  unifying  primary  "index  key"  for  data 
identification.  Data  could  be  efficiently  stored  based  upon  a 
single  data  base  entry  of  each  new  data  element,  data  storage 
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space  would  be  minimized,  and  retrievals  and  outputs  could  be 
readily  generated  based  upon  the  ordering  of  the  stored  data  by 
GPN,  GSN,  date  associated  with  this  data,  and  the  type  of  data 
being  stored . 

The  data  base  management  portion  of  the  TRIP  Data  Bank  must 
provide  the  following  minimum  functions: 

• Input  editing; 

• Error  correction; 

• Data  base  update; 

• Data  access/retrieval. 

Two  basic  types  of  editing  are  required  on  all  data  base 
transactions.  The  first  is  to  ensure  that  the  transaction  is  an 
allowable  function,  namely:  add,  modify,  delete,  or 

access/retrieve.  •All  four  of  these  functions  may  be  "allowable" 
with  respect  to  an  entire  record,  but  not  to  an  individual  data 
element  within  the  record.  Modification  of  the  record  type  key 
field,  for  example,  should  not  be  allowed  since  this  field 
defines  the  format  and  content  of  the  data  record. 

The  second  type  of  editing  is  to  check  the  incoming 
transaction  for  syntax  (order  of  elements,  left/right 

justification  of  data  fields,  alpha  versus  numeric  characters, 
etc.)  and  content  ( range/ tolerance , specific  value,  etc.).  Data 
base  transactions  which  fail  either  type  of  editing  should  be 
written  to  an  error  file  for  examination  and  correction  by  the 
operations  personnel.  The  data  base  management  software, 
therefore,  must  also  contain  the  functions  necessary  for 
correcting  these  records. 

Control  of  the  editing  process  could  be  accomplished  through 
the  use  of  a data  base  "Dictionary".  The  Dictionary  itself  is 
the  master  format  or  description  file  for  data  being  input, 
stored,  or  retrieved  from  the  data  base.  To  provide  this  master 
format  control  capability,  the  data  base  Dictionary  contains: 

• Complete  descriptions  of  all  data  base  input  record 
types,  including: 

Data  elements  within  each  record  type; 

Sequence  of  data  elements  within  each  record  type; 

Field  length  of  all  data  elements; 

• Complete  listing  of  all  valid  Generic  Part  Numbers  being 
accepted  into  the  Data  Bank  (i.e.,  a "Master"  Generic 
Parts  Li st) ; 

• Tolerance  tables  containing  the  range  of  allowable  values 
for  critical  data  items; 
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• Complete  descriptions  of  all  record  types  as  they  appear 
on  the  data  base. 

A second  level  of  editing  should  be  provided  by  the  software 
that  performs  the  actual  data  base  update  function.  Once  the 

input  data  has  been  checked  for  proper  format  and  content,  the 

"key"  elements  (GPN,  GSN,  date,  subdate,  and  record  type)  should 
be  compared  to  data  already  stored  on  the  data  base  in  order  to 
avoid  duplicate  entries.  If  a duplicate  key  is  found  on  the  data 
base,  the  individual  data  elements  of  the  record  already  on  the 
data  base  should  also  be  compared  with  the  "new"  record.  If 
they,  too,  are  duplicate,  the  "new"  record  should  be  "dropped"  as 
a duplicate  submission.  If  the  individual  data  elements  of  the 
"new"  record  differ  by  at  least  one  field  from  those  in  the 

record  already  on  the  data  base,  the  "new"  record  should  be 

written  to  an  error  file  for  examination  by  the  operations 
personnel.  If  the  record  is  determined  to  be  a valid 
transaction,  then  the  "subdate"  key  field  should  be  incremented 
and  the  record  re-processed. 

The  data  base  update  function  should  also  include  the 
capability  to: 

• Modify  data  already  on  the  data  base  (individual  and/or 
global)  : 

Modify  selected  key  elements; 

Modify  data  elements; 

Check  for  existence  of  data  elements; 

• Retire/delete  from  the  data  base  (entire  records  only): 

Individual  records; 

Record  groups,  where  the  "groups"  are  defined  by  a 
single  or  combination  of  key  elements  (GPN,  GSN,  date, 
or  record  type) . 

Some  special  investigations  may  require  access  to  the  entire 
TRIP  data  base.  The  organization  and  structure  of  the  data  base 
and  design  of  the  data  base  management  software,  therefore, 
should  allow  access  to  the  stored  records,  in  whole  or  in  part, 
on  the  basis  of  one  or  more  discrete  data  elements  of  the  record. 

Most  analyses,  however,  will  require  only  a subset  of  the 
data.  The  primary  method  of  retrieving  data,  therefore,  will  be 
via  range  or  discrete  value  testing  of  one  or  more  key  elements 
of  the  data  records.  The  objective  of  subsetting  the  data  base 
is  to  reduce  the  amount  of  data  to  be  processed  to  a manageable 
volume  and  thereby  minimize  processing  costs. 
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4. 3*2. 4 Data  Reporting 


The  primary  objective  of  the  TRIP  Data  Bank  is  to  provide 
information  on  the  reliability  and  associated  utilization  of 
transit  equipment  and  systems.  This  objective  will  be  met 
through  the  production  and  distribution  of  reports  which  present 
the  results  of  analyses  of  vehicle  and  equipment  operating  and 
maintenance  data  which  has  been  collected  and  stored  in  the  Data 
Bank.  Reports  will  also  be  produced  which  present  reference 
information  on  transit  properties,  vehicle  types,  and  associated 
equipment.  These  reference  data  reports  will  be  used  for  the 
interpretation  and  comparison  of  the  reliability  and  utilization 
reports. 

Outputs  and  reports  to  be  generated  by  TRIP  will  be  of  both 
routine  and  special  types.  Output  capabilities  of  the  system 
should  provide  for  the  prompt  and  efficient  production  of 
periodic  reports  on  fleet,  vehicle,  and  component  reliability  and 
performance.  Output  capabilities  must  also  have  the  flexibility 
to  format  and  produce  reports  for  special  data  retrievals  and 
analyses.  Routine  report  generation  capabilities  should  likewise 
retain  the  flexibility  to  be  modified  in  a timely  and  efficient 
manner  based  upon  changes  in  reporting  requirements. 

The  generation  of  routine  reports  will  require  handling 
large  quantities  of  vehicle  operation,  maintenance,  and  failure 
data  from  a number  of  sources.  This  data  must  be  input  into 
TRIP,  converted  into  a common  format  so  that  comparison  is 
possible,  and  analyzed  and  summarized  to  produce  these  reports. 
Typical  functions  required  for  the  production  of  routine  output 
reports  include: 

• Tabular  summaries  of  data: 

System  (Vehicle,  Power  & Way,  etc.); 

Property; 

Industry; 

• Arithmetic  computations: 

Sums; 

Averages; 

Percentages; 

• Statistical  calculations: 

Mean; 

Standard  deviation; 

Curve  fitting; 

• Plotting: 

Trend  plots; 
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Bar  charts; 

Histograms. 

The  generation  of  special  reports  requires  that  the  TRIP 
Data  Bank  have  the  capability  to  store  and  retrieve  data  on 
transit  equipment  down  to  the  "Lowest  Replaceable  Unit"  (LRU) 
level  of  detail.  In  order  to  support  component  tracking  and 
prototype  performance  analysis,  each  LRU  must  be  traceable  by 
serial  number.  Reference  (specification,  configuration,  and 
operating  environment)  data  will  also  play  a major  role  in 
special  analyses  by  providing  the  background  information 
necessary  for  comparative  analysis.  The  TRIP  Data  Bank, 
therefore,  must  be  capable  of  simultaneous  retrieval  of  different 
types  of  data. 

Although  a primary  goal  of  TRIP  is  to  provide  a central 
repository  containing  all  collected  transit  equipment  failure  and 
reliability  information,  the  usefulness  of  this  data  will  also 
depend  upon  the  promptness  and  flexibility  with  which  this  stored 
information  can  be  retrieved,  and  the  methods  which  are  available 
for  analysis  and  reporting. 
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5.  TRIP  DATA  BANK  RECOMMENDATIONS 


Detailed  functional  and  operating  considerations  which 
should  be  addressed  for  the  implementation  of  the  full-scale  TRIP 
Data  Bank  have  been  previously  described  in  Section  4.  Of  equal 
importance  are  the  recommendations  and  factors  which  should  also 
be  considered  as  part  of  the  implementation,  expansion,  and 
operation  of  the  full-scale  Data  Bank.  This  section,  therefore, 
addresses  the  following  program  issues  related  to  the  management 
of  TRIP: 

• Alternative  approaches  for  the  implementation  of  the 
full-scale  Data  Bank; 

• Considerations  for  the  expansion  of  the  Data  Bank  from 
the  experimental  to  full-scale  configuration; 

• Considerations  for  the  long-term  operation  of  the  TRIP 
Data  Bank. 


5.1  DATA  BANK  IMPLEMENTATION  ALTERNATIVES 


Due  to  the  anticipated  size  and  operating  cost  of  the 
full-scale  Data  Bank,  careful  consideration  should  be  given  to 
the  selection  of  the  group  or  organization  which  will  provide  the 
long-term  operating  capabilities.  Further,  organizational 
alternatives  for  the  implementation  of  the  full-scale  Data  Bank 
should  be  evaluated  with  respect  to  the  cost,  effort,  time,  and 
possible  risks  associated  with  each  alternative. 

The  organizational  alternatives  for  Data  Bank  implementation 


include : 

Alternative 

U 

Continued  sponsorship  by  the  U.S.  DOT;  continued 
operation  by  the  current  (EDB)  contractor. 

Alternative 

2: 

Continued  sponsorship  by  the  U.S.  DOT; 
by  a new  contractor. 

operation 

Alternative 

3: 

Installation  at  an  existing  U.S.  DOT 
cessing  facility;  use  of  UMTA-developed 

data  pro- 
software. 

Alternative 

4: 

Organization  of  a new  UMTA  data 

processing 

facility;  use  of  UMTA-developed  software. 


An  overview  comparison  of  the  factors  for  each  of  these 
alternatives  is  shown  in  Figure  5-1.  As  might  be  expected. 
Alternative  1,  continued  operation  by  the  present  EDB  contractor, 
presents  the  fewest  potential  additional  requirements  which  would 
have  to  be  addressed  for  implementation,  expansion,  and  operation 
of  the  full-scale  Data  Bank.  The  only  considerations  to  be 
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FIGURE  5-1 

FULL-SCALE  TRIP  DATA  BANK 
ALTERNATIVES  IMPLEMENTATION  REQUIREMENTS 


addressed  would  be  the  continuation  of  the  expansion  of  the  Data 
Bank  coverage  begun  during  the  EDB  implementation,  and  the 
addition  of  staff  to  handle  the  expanded  work  load. 

Alternative  2,  transfer  of  the  operation  of  the  Data  Bank  to 
a new  contractor,  raises  a series  of  issues  which  would  have  to 
be  addressed.  First,  a completely  new  staff  organization  would 
have  to  be  familiarized  and  trained  in  the  operation  of  the  Data 
Bank.  Second,  all  interface  procedures  with  the  participating 
transit  properties  would  have  to  be  re-established,  including 
liaison  with  the  property  and  Data  Bank  representatives,  and 
modification  of  data  transmission  procedures.  Third  and  finally, 
the  Data  Base  itself,  along  with  its  operating  software,  would 
have  to  be  transferred  to  the  new  Data  Bank  operator.  This 
transfer  process  would  include:  conversion  and  transfer  of 

software  developed  for  TRIP;  development  and/or  tailoring  of 
software  for  the  storage  of  the  data  itself;  implementation  and 
testing  of  the  complete  software  system  prior  to  transfer  of  the 
data  contained  in  the  (experimental)  Data  Bank;  and  parallel 
operation  of  the  Data  Bank  at  the  EDB  and  new  contractor 
facilities  until  the  new  software  is  in  place  and  operationally 
proven  to  prevent  a major  gap  in  historical  data  already 
contained  in  the  Data  Bank  through  the  operation  of  the  EDB. 

Alternative  3,  operation  by  the  Government  at  an  existing 
Government  data  processing  facility,  would  require  addressing  the 
same  set  of  issues  raised  by  Alternative  2,  above.  Alternative 
4,  operation  by  the  Government  at  a new  data  processing  facility 
established  by  the  Government  specifically  for  TRIP,  would  add  to 
the  concerns  of  Alternative  3 those  considerations  and 
requirements  of  purchasing  and  installing  the  new  computer 
hardware  itself.  These  hardware  considerations,  of  course,  have 
to  be  evaluated  in  parallel  with  the  considerations  for 
transition  of  the  Data  Bank  software. 

General  considerations  which  should  be  addressed  in  the 
evaluation  and  selection  of  implementation  alternatives  include: 

• Does  the  new  operations  staff  have  adequate  transit 
property  and  equipment  knowledge  and  experience  to 
validate  input  and  output  data  and  interface  with 
property  personnel? 

• Has  a realistic  and  supportive  estimate  been  supplied  as 

to  the  labor,  cost,  and  time  required  to  transfer, 

develop/ tailor , and  validate  new  operating  software,  if 
required? 

• Has  an  adequate  acceptance  testing  and  transition  plan 

been  provided  to  determine  the  time  and  cost  for  the 

transfer  of  the  Data  Bank  operation? 

• How  do  the  costs  and  time  required  for  transfer  compare 

to  the  program  benefits? 
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5.2 


DATA  BASE  EXPANSION 


Regardless  of  which  implementation  alternative  is  selected, 
the  Data  Bank  operations  staff  will  have  to  develop  a thorough 
and  comprehensive  approach  for  the  expansion  of  the  coverage  of 
the  Data  Bank.  This  expansion  approach  should  include: 

• Progressive  expansion  of  the  equipment  and  properties 
monitored  by  the  Data  Bank,  and  especially  the  expansion 
of  the  Generic  Parts  Lists; 

• Maintenance  of  systematic  procedures  during  the  expansion 
process  to  insure  data  handling  and  operating  procedures 
consistency ; 

• Technical  support  in  the  form  of  additional  experienced 
staff  to  assist  in  the  expansion  effort. 

After  evaluation  of  the  EDB  implementation  experience,  DRC 
has  concluded  that  the  expansion  of  the  monitoring  coverage  for 
equipment  and  properties  should  be  conducted  in  the  following 
sequence  of  steps: 


1 . 

Complete  c^ 

overage 

( i . 

e.,  Generic  Parts  Lists 

) of 

all 

equipment 

on  the 

V 

ehicles  c 

urrently  being  mo 

nitored 

by 

the  EDB. 

2. 

Expand  cov 

erage  to 

in 

elude  new 

vehicle  types  at 

the 

EDB 

properties 

• 

3. 

Expand  coverage 

to 

includ  e 

other  vehicle 

types 

at 

properties 

which  a 

re 

new  TRIP 

part ic ipant s . 

4. 

Finally , 

expand 

cov 

erage  to 

include  other 

types 

of 

equipment 

beyond 

the 

vehicle 

itself  (e.g.,  wayside  tr 

ain 

control  equipment. 

el 

ectr ifica 

tion  equipment. 

track 

and 

structures 

, etc . ) . 

These  proposed  steps  in  the  expansion  of  the  TRIP  Data  Bank 
coverage  provide  a controlled  approach  to  add  to  the  Generic 
Parts  Lists,  augment  data  input  and  handling  procedures,  and  add 
to  the  operations  staff  to  deal  with  the  increasing  work  load. 
While  no  rate  of  coverage  expansion  has  been  suggested,  the  goal 
of  TRIP  to  support  new  vehicle  acquisition  points  toward  a more 
rapid  expansion  in  order  to  support  the  information  needs  of  the 
industry  regarding  the  current  influx  of  new  vehicles. 

Throughout  the  expansion  process,  the  operations  staff  must 
insure  that  all  procedures  for  operation  are  continuing  to  be 
systematically  applied.  Of  primary  importance  is  the  strict 
control  of  the  development  of  the  Generic  Parts  Lists  (GPLs) . 
The  GPLs,  as  the  index,  dictionary,  and  cross-reference  to  the 
data  stored  in  the  data  base,  must  be  completely  accurate  and 
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consistent.  Each  addition  to  the  GPLs  must  strictly  follow 
procedures  for  development  and  implementation  that  have  been  used 
throughout  the  program. 

An  important  further  consideration  in  the  expansion  of  the 
Data  Bank  coverage  is  the  availability  of  technical  personnel  to 
support  this  activity.  This  added  technical  staff  will  be 
initially  required  for  the  development  of  new  GPLs. 
Subsequently,  this  same  staff  will  be  required  for  the  expansion 
of  the  associated  data  collection,  data  entry,  and  data  handling 
procedures.  Finally,  this  staff  will  support  the  expansion  of 
the  output  reporting  coverage  to  include  the  new  equipment, 
vehicle  types,  and  properties  being  monitored. 

This  added  technical  staff  must  have  experience  with  both 
transit  properties  and  equipment.  Equipment  knowledge  will  be 
vital  for  proper  and  timely  development  of  GPLs.  Property 
experience  will  be  useful  for  the  development  of  data  collection 
and  validation  procedures  required  for  each  new  data  source. 
Property  experience  will  also  be  imperative  for  the  continued 
refinement  and  improvement  of  Data  Bank  output  information  and 
reports  to  make  them  as  useful  to  the  participants  as  possible. 


5.3  DATA  BASE  OPERATION 


In  order  to 
operation  of  the 
will  be  required. 


support  both  the  expansion  and 
full-scale  TRIP  Data  Bank,  certain 
These  resources  include: 


long-term 

resources 


• Knowledgeable  staff  --  who  are  experienced  in  both  data 
processing  and  transit  equipment; 

• Dedicated  personnel  and  hardware  --  to  insure  that  top 
priority  is  given  to  the  operation  of  the  system  and  the 
production  of  outputs; 

• Engineering  support  --  to  insure  the  validity  of 
analyses  and  respond  to  requests  for  special  data 
retrievals  and  analyses. 


The  success  of  the  TRIP  effort  is  based  upon  the  quality  and 
dedication  of  the  staff  provided  for  the  operation  of  the  Data 
Bank.  This  staff  has,  as  a program  responsibility,  the  task  of 
insuring  the  quality  of  the  data  contained  in  the  data  base. 
This  data  quality  control  depends  upon  the  staff's  capabilities 
to  detect  and  correct  data  anomalies  and  errors  based  upon  its 
knowledge  and  experience  with  transit  equipment  and  its 
functional  characteristics.  In  the  same  way,  the  operations 
staff  must  also  insure  the  reasonableness  and  accuracy  of  output 
reports  produced  from  the  system.  Finally,  the  participants 
themselves  must  provide  a knowledgeable  interface  to  address 
users'  needs,  answer  questions,  and  provide  information. 


44 


In  order  to  provide  for  the  consistent  and  effective 
operation  of  the  Data  Bank,  both  dedicated  personnel  and 
automated  data  processing  hardware  are  required.  Dedicated  staff 
is  imperative  to  insure  that  all  operations  tasks,  especially 
data  entry,  are  dealt  with  promptly,  and  that  personnel  are  not 
diverted  to  other  activities.  Dedicated  data  processing 
equipment  will  insure  that  the  data  quality  and  integrity  is 
maintained  as  well  as  remains  under  the  control  of  the  operations 
staff. 

Finally,  it  is  important  that  long-term  engineering  support 
be  provided  as  an  integral  part  of  the  operation  of  the 
full-scale  Data  Bank.  The  success  of  TRIP  would  potentially  be 
brought  into  question  if  the  operation  of  the  Data  Bank  becomes 
merely  a "data  processing"  operation.  The  value  and  usefulness 
of  the  program  is  predicated  on  its  ability  to  address 

equipment-related  engineering  questions,  investigations,  and 
analyses.  To  meet  this  continuing  objective,  ongoing  engineering 
support  is  required.  This  engineering  capability  will  be  used 
to:  continue  to  evaluate,  refine,  and  improve  the  output 

products  of  the  Data  Bank;  resolve  more  complex  data  anomalies; 
define  and  conduct  engineering  analyses  and  the  preparation  of 
reports  in  response  to  special  requests  from  users  of  the  TRIP 
Data  Bank. 
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6.  CONTRACT  TASK  SUMMARY 


The  purpose  of  this  section  is  to  present  a summary  of  the 
results  achieved  and  conclusions  reached  during  each  of  the 
twelve  tasks  of  Contract  Number  DOT-TSC- 1 559 • The  approach  taken 
by  the  Dynamics  Research  Corporation  (DRC)  for  this  contract  is 
illustrated  in  Figure  6-1. 

On  September  18,  1978,  Dynamics  Research  Corporation  (DRC) 
began  work  on  Contract  Number  DOT-TSC-1559  to  define,  develop, 
and  establish  the  Transit  Reliability  Information  Program 
(TRIP) . The  objective  of  this  effort  is  to  develop  a 
comprehensive  coordinated  approach  to  transit  vehicle  reliability 
assessment  by  satisfying  the  following  program  requirements: 

• Consolidated  data  system  to  provide  a central  source  of 
reliability  information  for  all  transit  vehicles  which 
will  collect,  screen,  and  store  the  necessary  data; 

• Reliability  data  analysis  including  determination  of  the 
type  and  quantity  of  data  to  be  collected,  methods  for 
analyzing  and  summarizing  input  data,  and  analytical 
approaches  for  detailed  reliability  investigations; 

• Reliability  assessment  support  to  assist  participants  and 
other  groups  in  reliability  research  and  analysis  by 
providing  prompt,  timely  outputs  and  reports,  and  by 
providing  the  capability  for  special  data  searches  and 
analyses . 

The  major  aspects  of  the  technical  approach  proposed  by  DRC 
for  TRIP  were  to: 

• Define  and  document  TRIP  functional  and  operational 
requirements  necessary  to  satisfy  the  aforementioned 
program  requirements; 

• Develop,  establish,  and  operate  an  Experimental  Data  Bank 
(EDB)  as  a prototype  of  the  full-scale  TRIP  Data  Bank  for 
the  purpose  of  evaluating  the  proposed  methodology; 

• Establish  the  (full-scale)  TRIP  Data  Bank. 

The  first  two  activities  comprise  Phase  I of  the  contract 
effort  and  cover  the  planning,  designing,  and  testing  of  a small 
scale  (experimental)  data  bank.  The  purpose  of  the  Experimental 
Data  Bank  (EDB)  is  to  provide  a working  "model"  which  can  be  used 
to  evaluate  the  concepts  of  the  full-scale  TRIP  Data  Bank 
developed  during  the  first  major  activity  above,  and  to  refine 
procedures  for  the  acquisition,  storage,  retrieval,  and 

application  of-  the  output  reports.  The  results  of  this 
evaluation  will  by  used  to  formulate  recommendations  for 

continuing  the  operation  of  the  Data  Bank  and  expansion  into  a 


46 


II  aSVHd  • 38VH4 


47 


DEFINITION,  SCOPE,  PRESENTATION  OPERATION,  EVALUATION  ESTABLISHMENT 


full-scale  system  during  Phase  II. 

The  implementation  and  subsequent  operation  of  the  EDB  was 
based  upon  the  voluntary  participation  of  six  operating  transit 
properties  who  are  supplying  data  to  TRIP.  Because  of  unexpected 
and  changing  circumstances  at  four  of  these  properties,  TRIP 
experienced  delays  in  the  initiation  of  EDB  operation  due  to 
slower-than-expected  accumulation  of  background  information 
necessary  for  executing  the  design  of  the  system  as  well  as  the 
transit  vehicle  data  itself  which  is  the  input  data  for  the 
system.  The  insufficiency  of  data  resulted  in  the  inability  to 
adequately  exercise  the  Data  Bank  concept  within  the  time  period 
originally  specified  for  the  contract. 

A modification  to  Contract  Number  DOT-TSC-1559  was 

subsequently  issued  which  increased  the  period  of  performance  of 
Phase  I (specifically,  Tasks  7-9)  by  nine  months.  This 
extended  period  of  EDB  operation  and  refinement  produced  the 
following  results: 

• Provided  a more  thorough  evaluation  of  TRIP  Data  Bank 
design  concepts; 

• Provided  a more  comprehensive  assessment  of  the 

operational  requirements  for  the  full-scale  TRIP  Data 
Bank; 

® Provided  a better  opportunity  for  the  APTA  TRIP  Liaison 
Board  to  participate  in  the  continued  development  and 
refinement  of  TRIP  output  reports; 

e Provided  more  complete  and  detailed  information  for  the 
EDB  evaluation  presented  at  the  Critical  Design  Review 
(CDR). 

Prior  to  the  CDR,  "Phase  I"  of  Contract  Number  DOT-TSC-1559 
and  "Phase  I"  of  the  TSC  TRIP  Implementation  Plan  had  been 
concurrent  events.  The  net  effect  of  the  CDR  was  to  extend  the 
duration  of  Phase  I of  the  Implementation  Plan,  postponing 
implementation  of  Phase  II  for  15  - 21  months. 

The  original  purpose  of  Phase  II  of  the  contract  was  to 
provide  transition  support  for  the  lead-in  to  Phase  II  of  the  TSC 
Implementation  Plan.  Data  preparation  assistance  from  Task  7 was 
to  be  continued  in  Task  11,  and  EDB  operation  from  Task  8 was  to 
be  continued  in  Task  12,  while  a separately  contracted  effort  was 
to  be  initiated  to  establish  a full-scale  TRIP  Data  Bank. 

Because  of  the  CDR  outcome,  however,  the  objective  of  Phase 
II  of  the  contract  was  redirected  from  a posture  of  maintaining 
EDB  operation  until  the  full-scale  Data  Bank  was  established,  to 
maintaining  EDB  operation  until  a "continuation  contract"  could 
be  issued  to  continue  EDB  operation,  refinement,  and  expansion  as 
recommended  by  the  CDR  committee. 
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In  keeping  with  this  shift  in  emphasis,  the  contract  task 
summary  presented  in  the  following  subsections  considers  Tasks 
11  & 12  to  be  post-CDR  contiguous  extensions  of  Tasks  7 & 8, 
r espectiv  ely . 


6.1  TASK  1 --  EVALUATE/ ASSESS  DATA  BANKS/  POOLS 


The  activities  of  Task  1 are  illustrated  in  Figure  6-2.  The 
purpose  of  Task  1 was  to: 

• Characterize  the  types,  formats,  and  quantities  of 
available  transit  vehicle  operating,  maintenance,  and 
failure  data  to  be  used  for  the  development  of  the  TRIP 
Data  Bank  input  and  output  procedures; 

• Define  transit  vehicle  hardware  configurations,  through 
parts  breakdowns,  as  the  basis  for  the  development  of 
both  Reliability  Equipment  Lists  in  Task  3 and  the  Data 
Bank  storage  structure  in  Task  2; 

• Scope  transit  property  and  vehicle  reference,  or 
background,  information  to  be  used  to  interpret 
reliability  information  to  be  produced  by  the  TRIP  Data 
Bank; 

• Evaluate  the  configuration  and  operating  methods  of 

existing  reliability  data  banks  to  assess  the 

applicability  of  these  approaches  to  the  design  of  the 
TRIP  Data  Bank. 

The  approach  used  for  the  Task  1 investigations  was  to  visit 
transit  properties  to  collect  the  designated  information  and  to 
visit  an  existing  reliability  data  bank  and  review  the  document 
and  outputs  of  a number  of  other  existing  data  banks. 

The  transit  properties  which  were  visited  were  those 
selected  as  a cross-section  sample  for  participation  in  the  TRIP 
Experimental  Data  Bank.  These  properties  are: 

BART  Bay  Area  Rapid  Transit  District; 

CTA  Chicago  Transit  Authority; 

GCRTA  Greater  Cleveland  Regional  Transit  Authority; 

NYCTA  New  York  City  Transit  Authority; 

PATCO  Port  Authority  Transit  Corporation; 

WMATA  Washington  Metropolitan  Area  Transit 

Authority, 

Existing  reliability  data  banks  which  were  investigated 
included:  the  Government  - Industry  Data  Exchange  Program 

(GIDEP);  Reliability  Analysis  Center  (RAC);  two  U.S.  Military 
Maintenance  data  systems;  and  the  DRC  Technical  Integrated  Data 
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FIGURE  6-2.  LOCATE  & ASSESS  EXISTING  DATA  BANKS  & SOURCES  (TASK  1) 


System  ( TIDS) . 


The  Task  I effort  was  completed  in  December  1978.  The 
following  conclusions  were  reached  based  on  the  investigation  of 
data  banks  external  to  the  transit  industry: 

• No  publicly  available  data  bank  exists  for  transit- 
specific  components; 

• Existing  reliability  data  systems  (eg:  GIDEP,  RAC, 
AFM  66-1,  USN  3M)  do  not  differentiate  between  primary 
and  secondary  failures  and  therefore  provide  "practical” 
rather  than  "classical"  reliability  information  from 
their  data; 

• The  Government  - Industry  Data  Exchange  Program  (GIDEP) 
offers  the  potential  of  becoming  the  point  of 
distribution  for  the  outputs  from  the  TRIP  Data  Bank; 

• The  publications  of  the  Reliability  Analysis  Center,  Rome 
Air  Development  Center  (RAC/RADC),  provide  a good  example 
for  the  presentation  of  reliability  information  and  offer 
suggested  analyses  for  reliability  assessment  which  are 
suitable  for  inclusion  in  TRIP; 

• U.S.  Military  Maintenance  Data  Systems,  particularly  the 
Air  Force  AFM  66-1  and  Navy  3M  systems,  provide  good 
examples  of  "generic"  approaches  to  equipment 
hierarchical  descriptions  and  failure/repair  coding  which 
directly  correspond  to  the  intended  approach  for  the  TRIP 
Data  Bank; 

• DRC’s  Technical  Integrated  Data  System  (TIDS)  provides  a 
basis  for  the  development  of  the  TRIP  Data  Bank  through 
its  modular  approach  to  system  design; 

The  investigation  of  existing  sources  of  reliability 
information  on  transit  vehicle  equipment  and,  in  particular,  the 
survey  of  the  six  transit  properties  that  are  participating  in 
the  development  of  the  TRIP  Data  Bank  have  yielded  the  following 
observations  and  conclusions: 

• The  total  extent  of  data  that  would  normally  be  collected 
to  support  the  classical,  detailed  reliability  analysis 
of  transit  equipment  is  not  available  unilaterally; 

• Tracking  of  serialized  equipment  is  done  for  only  a few 
major  (high  cost)  assemblies; 

• No  differentiation  is  made  between  primary  and  secondary 
failures ; 

• Failure  data  is  recorded  to  different  levels  of  equipment 
detail  at  different  properties  (e.g.,  only  to  subsystem 
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level  versus  to  the  component  level) ; 

• Transit  properties  are  most  interested  in  tracking  the 
latest  vehicle  or  hardware  types; 

• Vehicle  configuration  data,  while  available,  must  be 
correlated  from  several  sources  at  each  property  to 
produce  cross-reference  lists  of  property  and 
manufacturer's  part  numbers; 

• Transit  property  reference  data  (e.g.,  maintenance 

activity  codes,  failure  codes,  etc.)  must  be  correlated 
into  "generic"  cross-reference  lists  for  comparison 
between  properties; 

• The  majority  of  the  properties  (5/6)  use  mileage  as  the 
basis  for  preventative  maintenance  and  failure  rate 
determination ; 

• Only  that  maintenance  data  which  pertains  to  what  was 
done  to  and  on  the  vehicle  itself  (primary  maintenance) 
can  be  correlated  to  a vehicle  failure  event  (except  at 
BART) ; 

• Secondary  (bench)  maintenance  of  components  removed  from 
a vehicle  cannot  be  traced  to  a vehicle  failure  event 
through  existing  data  forms  (except  at  BART); 

• Where  a choice  existed,  the  transit  properties  selected 
their  most  recently  purchased  vehicles  for  inclusion  in 
the  TRIP  EDB. 

Based  upon  the  conclusions  of  the  investigations  of  this 
task,  the  following  recommendations  were  made  and  integrated  into 
subsequent  tasks: 

• Further  discussions  should  be  conducted  with  GIDEP  for 
setting  up  a separate  data  bank  for  TRIP  information 
when  it  becomes  available; 

• Careful  consideration  should  be  given  to  the  use  of  TIDS 
as  the  basis  for  the  design  of  the  TRIP  Data  Bank; 

• A generic  coding  scheme  should  be  developed  for  failure, 
maintenance,  and  other  codes  and  information  recorded  by 
individual  transit  properties; 

• Consideration  should  be  given  to  the  storage  of 
maintenance  narrative  data  as  well  as  parts  cost,  labor 
types,  and  repair  times,  as  correlative  information; 

• Selection  of  components  to  be  tracked  in  the  EDB  should 
be  made  in  light  of  results  which  can  be  produced  in  6-8 
months.  This  may  involve  the  consideration  of  components 
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based  primarily  on  their  failure  rates; 

• Components  to  be  tracked  in  the  EDB  should  include  the 

most  recent  technology  (e.g.,  chopper  versus  cam 

propulsion  control)  which  have  generated  significant 

industry  interest; 

• Procedures  should  be  developed  to  process  hard-copy 
maintenance  data,  where  that  is  the  only  format  in  which 
the  data  is  available,  including  the  coding  of  narrative 
information  concerning  affected  hardware,  failure  type, 
and  action  taken. 

A detailed  discussion  of  the  results,  conclusions,  and 
recommendations  of  the  Task  1 activities  is  contained  in  DRC 
Report  Number  E-4852U. 


6.2  TASK  2 --  DEFINE/SCOPE  TRIP  DATA  BANK 


The  activities  of  Task  2 are  illustrated  in  Figure  6-3.  The 
major  areas  addressed  in  Task  2 were: 

• Definition  and  scope  of  the  full-scale  TRIP  Data  Bank 
configuration ; 

• Definition  and  scope  of  the  Experimental  Data  Bank  (EDB) 
configuration  as  the  intermediate  step  toward  the 
efficient  development  of  the  full-scale  Data  Bank; 

• Characterization  of  rail  transit  vehicle  operating, 
maintenance,  repair,  and  reference  data  to  be  used  as 
input  for  the  Data  Bank; 

• Definition  of  potential  outputs  and  reports  to  be 
produced  by  the  Data  Bank; 

• Scoping  of  operating  requirements  for  the  full-scale  Data 

Bank,  including:  operating  methods  and  procedures, 

estimated  Data  Bank  size,  and  projected  Data  Bank 
staffing ; 

• Scoping  of  cost  factors  for  the  full-scale  Data  Bank, 
including:  operating  costs,  program  sponsorship,  etc.; 

• Scoping  of  projected  benefits  to  be  derived  from  the 

full-scale  TRIP  Data  Bank  and  associated  cost 

justification . 

Significant  input  to  the  definition  and  scoping  effort  of 
Task  2 was  provided  by  work  which  was  simultaneously  conducted  on 
Tasks  1 and  3.  Information  provided  by  the  Task  1 investigation 
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FIGURE  6-3.  DEFIIME/SCOPE  TRIP  RELIABILITY  DATA  BANK  (TASK  2) 


and  assessment  of  existing  reliability  data  banks  and  rail 
transit  vehicle  data  sources  included: 

• Format,  content,  and  estimated  quantity  of  utilization, 
maintenance,  and  repair  data  for  rail  transit  vehicles 
available  from  transit  properties  to  be  used  for  Data 
Bank  input; 

• Format,  content,  and  availability  of  reference  data 
covering  transit  property,  rail  transit  vehicle,  and 
vehicle  hardware  characteristics  and  operating  policies 
to  be  stored  in  the  Data  Bank; 

• Examples  of  reliability  information  and  reports  being 
currently  generated  by  individual  transit  properties  to 
be  used  for  the  definition  of  TRIP  outputs; 

• Operating  procedures  and  methods  of  existing  reliability 
data  banks,  including  output  generation,  and  reporting, 
input  data  processing,  and  information  distribution,  to 
be  used  for  the  development  of  the  TRIP  Data  Bank 
operating  approach. 

Information  provided  by  the  Task  3 development  of 

Reliability  Equipment  Lists  which  was  used  in  the  Data  Bank 
definition  and  scoping  effort  included: 

• Classification  of  rail  transit  vehicle  equipment  using  a 
function-oriented  Generic  Part  Numbering  approach  as  the 
basis  for  the  organization  of  the  Data  Bank  data  storage 
approach ; 

• Rail  transit  vehicle  equipment  Generic  Part  Numbering  as 
the  basis  for  the  development  of  common  formatting  of 
data  from  several  sources; 

• Operating  procedures  for  adding,  deleting,  or  modifying 
equipment  to  be  tracked  as  one  facet  of  the  Data  Bank 
operation . 

A major  effort  in  the  definition  and  scoping  of  the  TRIP 
Data  Bank  configuration  and  requirements  was  to  characterize  the 
available  rapid  rail  transit  vehicle  operating,  maintenance,  and 
inspection  data  which  would  be  used  as  input  for  TRIP.  The 
characteristics  of  the  available  data,  including  format,  content, 
and  commonality  between  sources,  provided  the  major  input  to  the 
development  of  Data  Bank  configuration  and  operating  requirements 
for  processing  and  storing  input  data.  This  information  also 
provided  a basis  for  defining  the  initial  format  of  output 
reports  to  be  produced  by  TRIP. 

It  should  be  noted  that  the  development  of  many  automated 
data  processing  systems  begins  with  the  definition  of  the  outputs 
to  be  produced.  Based  upon  this  definition,  input  data 
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requirements  are  established  along  with  data  processing 
requirements  to  convert  the  input  data  into  output  reports. 

The  specific  approach  taken  for  TRIP  differed  from  this 
general  design  approach  in  that  the  input  data  for  TRIP  was 
predefined  as  being  the  data  produced  by  the  transit  properties. 
The  "basic  philosophy"  of  TRIP  is  that  data  be  accepted  in  its 
organic  form,  and  no  additional  data  collection  or  reporting 
requirements  are  to  be  imposed  upon  the  data  sources.  The  design 
of  the  initial  output  reports  for  TRIP,  therefore,  was 
significantly  influenced  by  the  data  definitions  acquired  in  Task 
1 . 

The  Task  2 activities  were  completed  in  January  1979.  A 
detailed  presentation  of  the  initial  TRIP  Data  Bank  scope  and 
definition  is  contained  in  DRC  Report  Number  E-4894U. 


6.3  TASK  3 --  ESTABLISH/PRIORITIZE  RAPID  RAIL  EQUIPMENT  LISTS 


The  activities  of  Task  3 are  illustrated  in  Figure  6-4.  The 
objectives  of  the  Task  3 effort  were  to: 

• Establish  a uniform  system  of  rail  transit  vehicle 
component  identification  that  can  be  used  for  the  merging 
of  data  on  these  components  into  the  TRIP  Data  Bank; 

• Identify  pilot  rail  transit  equipment  to  be  monitored  by 
the  TRIP  Experimental  Data  Bank; 

• Develop  operating  procedures  for  modifying  the  list  of 
components  being  monitored  by  the  TRIP  Data  Bank; 

• Establish  a system  of  cross-referencing  components  by 
parameters  which  describe  the  characteristics, 
performance,  and  reliability  of  the  components. 

The  work  conducted  in  Task  3 was  based  upon  inputs  from  the 
completed  Task  1 effort  and  upon  the  concurrent  work  conducted 
for  Task  2 . The  approach  used  for  the  Task  3 effort  was  to: 

• Define  the  types  of  information  that  would  be  needed  to 
identify  transit  vehicle  components  and  to  acquire  same; 

• Define  the  types  and  content  of  equipment  lists  that 
would  be  needed  to  establish  and  operate  the  TRIP  Data 
Bank ; 

• Develop  and  demonstrate  a coding  scheme  to  support 
component  identification  and  integration  into  a common 
data  bank; 
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FIGURE  6-4.  DEVELOP  RELIABILITY  EQUIPMENT  LIST  (TASK  3) 


• Define  the  types  of  cross-referencing  information  that 
would  be  needed  to  supplement  the  reliability  information 
of  the  data  bank  output  reports  and  provide  a perspective 
for  interpreting  this  reliability  information. 

The  Task  3 effort  resulted  in  the  definition  of  the 
following  elements  of  the  TRIP  Data  Bank: 

• Generic  Serial  Number  (GSN) ; 

• Generic  Part  Number  (GPN); 

• Generic  Parts  List  (GPL); 

• Master  Generic  Parts  List  (MGPL); 

• Reliability  Equipment  List  (REL); 

• Master  Reliability  Equipment  List  (MREL); 

• Parametric  Characteristics  List  (PCD. 

The  preliminary  definitions  of  these  elements  are  contained 
in  DRC  Report  Number  E-4895U. 

The  Task  3 effort  also  resulted  in  the  development  of  the 
methodologies  necessary  to  define  the  basic  structure  of  the  TRIP 
Data  Bank  through  transit  vehicle  equipment  lists.  The  first 
draft  of  the  operating  procedures  for  developing  and  modifying 
these  equipment  lists  is  contained  in  DRC  Report  Number  E-4896U. 

Development  of  the  operating  procedures  was  completed  in 
January  1979.  This  methodology  was  then  applied  to  the 
preparation  of  Generic  Parts  Lists  for  the  first  five 

participants  in  the  Experimental  Data  Bank.  The  GPLs  for  BART 
and  WMATA  were  completed  in  June  1979;  for  PATCO  and  CTA  in 
September  1979;  and  for  NYCTA  in  January  1980. 


6.4  TASK  4 --  DEFINE/RECOMMEND/PREPARE  TRIP  GUIDLINES 


The  activities  of  Task  4 are  illustrated  in  Figure  6-5.  The 
objective  of  Task  4 was  to  produce  a guidelines  document  for 
participants  in  TRIP  describing  the  operation,  capabilities,  and 
use  of  the  TRIP  Data  Bank. 

An  interim  report  (DRC  Report  Number  E-4998U)  was  published 
in  April  1979  which  was  based  upon  the  preliminary  definition  of 
the  TRIP  Data  Bank  that  emerged  from  the  efforts  of  Tasks  1 - 3. 
This  document  provided  TRIP  participants  with  an  overview  of  the 
(then  emerging)  Data  Bank  design  and  operation.  Procedures  for 
submitting  data  and  a description  of  the  output  reports  to  be 


58 


i i 


• o>  c 

O 6 S 


|S§ 

J o 


(C 


• • 


59 


FIGURE  6-5.  DEFINE/RECOMMEND/PREPARE  GUIDELINES  (TASK  4) 
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FIGURE  6-6.  PREPARE/CONDUCT  REGIONAL  MEETING  PRESENTATIONS  (TASK  5) 


produced  were  also  included  in  the  interim  guidelines  document. 

The  Task  4 effort  focused  the  results  of  Tasks  1 - 3 into  a 
concise  definition  of  the  TRIP  Data  Bank.  It  was  from  this 
definition  that  the  operation  of  and  data  submission  to  the 
Experimental  Data  Bank  (EDB)  were  implemented  in  Tasks  7 & 3. 
The  guidelines  that  emerged  from  Task  4 also  formed  the  basis  of 
the  activities  performed  in  Tasks  5 & 6. 

The  Task  4 guidelines  document  was  subsequently  revised  to 
incorporate  the  many  enhancements  and  changes  that  occurred 
during  the  development,  operation,  and  refinement  of  the  TRIP  EDB 
during  Tasks  7-9.  The  revised  Task  4 document  was  published  in 
January  1981  as  "TRIP  Participants  Guidelines",  DRC  Final  Report 
Number  R-339U. 


6.5  TASK  5 — PREPARE/CONDUCT  REGIONAL  MEETING  PRESENTATIONS 


The  activities  of  Task  5 are  illustrated  in  Figure  6-6.  The 
purpose  of  Task  5 was  to  conduct  regional  meetings  designed  to 
familiarize  the  transit  properties  with  the  operation  and  use  of 
TRIP.  These  meetings  were  held  at  PATCO,  WMATA,  CTA,  GCRTA,  and 
NYCTA.  The  meetings  consisted  of  presentations  by  the  Government 
Technical  Monitor  for  TRIP,  Mr.  Richard  H.  Robichaud,  and  the 
DRC  TRIP  Program  Manager,  Mr.  Stanley  B.  Limpert.  The  TRIP 
presentations  were  given  in  two  parts;  (1)  A morning  executive 
session  providing  a broad  overview  of  the  program’s  operation  and 
potential  uses;  (2)  An  afternoon  detailed  session  explaining  the 
mechanics  of  data  entry,  storage,  and  extraction.  Each  session 
was  followed  by  a question  and  answer  period.  The  questions 
received  dealt  primarily  with  the  influence  TRIP  will  have  on: 

• Specifications  for  new  rail  equipment; 

• Upgrading  data  reporting  at  a given  property; 

• Warranty  assurance; 

• Production  and  use  of  special  reports. 

The  regional  meetings  also  provided  a forum  for  discussing 
data  collection  and  submission  procedures  that  were  to  be 
implemented  for  TRIP  at  each  of  the  properties  visited. 


6.6  TASK  6 --  RAILCAR  STANDARDIZATION  RELIABILITY  PLAN 


The  activities  of  Task  6 are  illustrated  in  Figure  6-7.  The 
objective  of  the  Task  6 effort  was  to  produce  a Reliability 


61 


FIGURE  6-7.  RAILCAR  STANDARDIZATION  RELIABILITY  PLAN  (TASK  6) 


Verification  Demonstration  Plan  for  Rapid  Rail  Vehicles.  The 
purpose  of  the  plan  was  to  provide  an  interface  between  TRIP  and 
the  Railcar  Standardization  Program. 

The  Reliability  Verification  Demonstration  (RVD)  Plan  was 
first  published  as  a draft  report  (DRC  Report  Number  E-5150U)  in 
August  1979.  The  purpose  of  the  document  was  to  familiarize 
potential  users  of  TRIP  with  the  Data  Bank  capabilities  and  data 
requirements  as  they  pertain  to  the  conduct  of  a Reliability 
Verification  Demonstration  Program.  A second  draft  was  produced 
in  October  1979  which,  in  contrast  to  the  first  draft,  placed 
more  emphasis  on  the  RVD  Plan  itself. 

These  two  drafts  were  integrated  into  a single  final  report 
(DRC  Report  Number  R-340U)  and  published  in  April  1980  as  "TRIP 
Reliability  Verification  Demonstration  Plan  for  Rapid  Rail 
Vehicles".  This  document  was  prepared  as  an  applications  manual 
for  the  TRIP  Data  Bank.  It  provides  the  user  with  both  an 
overview  of  TRIP  and  the  TRIP  Data  Bank,  and  guidelines  for 
planning  and  conducting  a Reliability  Verification  Demonstration 
Program  using  the  TRIP  Data  Bank  to  collect  and  process  the  data 
collected  during  the  program. 


6.7  TASKS  7 & 1 1 --  TRIP  EDB  DATA  PREPARATION  ASSISTANCE 


The  activities  of  Task  7 are  illustrated  in  Figure  6-8. 
There  were  three  major  objectives  to  Task  7: 

• Establish  and  maintain  a liaison  with  each  transit 
property  supplying  data  to  the  TRIP  Experimental  Data 
Bank  (EDB) ; 

• Assist  each  property  with  developing  and  implementing 
procedures  for  submitting  data  to  the  EDB; 

• Assist  each  property  as  required  with  data  submission. 

Task  7 was  performed  concurrently  with  Tasks  8 & 9.  The 
primary  liaisons  with  each  transit  property  were  established 
early  in  the  program  through  the  American  Public  Transit 

Association  (APTA)  TRIP  Liaison  Board.  Working  relationships 
were  established  with  the  representatives  and  other  personnel  of 
the  transit  properties  during  the  performance  of  earlier  tasks  in 
the  program. 

Routine  data  submission  was  begun  with  the  initial  five 
participating  properties  (BART,  WMATA,  PATCO,  CTA,  and  NYCTA,  in 
that  order)  as  the  EDB  was  implemented  to  accept  and  process 
their  data. 

A major  philosophy  of  TRIP  is  that  data  would  be  accepted 
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FIGURE  6-8.  EXPERIMENTAL  DATA  BANK  (EDB)  DATA  PREPARATION  ASSISTANCE  (TASK  7) 


from  transit  properties  in  its  organic  form.  "Data  preparation 
assistance"  was  subsequently  incorporated  into  the  very  design  of 
the  EDB  in  the  form  of  interactive  programs  to  enter  data  from 
hard-copy  forms  generated  by  the  properties,  with  the  data  entry 
labor  being  provided  by  TRIP  under  Task  7.  Similarly  for 
magnetic  tape  data  submission,  procedures  and  programs  were  set 
up  to  copy  the  data  from  the  property  tapes  onto  DRC  tapes  so 
that  the  property  tapes  could  be  returned  for  recycling.  The 
cost  of  the  magnetic  tape  itself  was  thus  eliminated  from  the 
cost  to  the  property  of  TRIP  participation. 

A unique  case  was  encountered  at  PATCO  where  input  data  was 
in  the  form  of  punched  cards.  In  order  to  facilitate  handling, 
data  preparation  assistance  to  PATCO  consisted  of  subcontracting 
with  a local  (to  PATCO)  computer  service  bureau  to  load  the  data 
from  the  cards  onto  a magnetic  tape.  The  magnetic  tape  was  thus 
used  as  the  input  media  to  the  EDB  with  the  program  assuming  the 
cost  of  media  conversion. 

When  the  period  of  performance  for  Task  7 expired  in 
September  1980,  data  preparation  assistance  transferred  to 
Task  11  of  the  contract. 


6.8  TASKS  8 & 12  --  ESTABLISH/OPERATE  EXPERIMENTAL  DATA  BANK 


The  activities  of  Task  8 are  illustrated  in  Figure  6-9.  The 
objective  of  Task  8 was  to  establish  and  operate  an  Experimental 
Data  Bank  (EDB)  as  a prototype  or  model  of  the  TRIP  Data  Bank  for 
the  purpose  of  validating  and  refining  the  Data  Bank  definition 
and  operating  guidelines  developed  in  Task  4. 

The  design  and  implementation  of  the  EDB  began  early  in 
1979.  The  APTA  TRIP  Liaison  Board  recommended  three  vehicle 
subsystems  (doors  and  door  controls,  propulsion,  and  friction 
brakes)  as  the  "pilot  equipment"  to  be  monitored  by  the  EDB. 
Using  the  procedures  and  definitions  developed  during  Task  3, 
Generic  Parts  Lists  for  these  three  systems  were  developed  for 
BART  and  WMATA.  (Changing  circumstances  at  CTA,  NYCTA,  and  PATCO 
forced  a postponement  in  the  development  of  their  GPLs.)  Software 
development  for  the  EDB  proceeded  during  the  first  half  of  1979, 
and  by  the  end  of  July,  the  EDB  was  ready  for  testing. 

Software  acceptance  tests  were  successfully  conducted  from 
July  30  to  August  3,  1979.  On  August  6,  1979,  the  TRIP 

Experimental  Data  Bank  began  operation  with  the  input  of  July 
data  from  BART  and  WMATA.  EDB  refinement  and  expansion  began  on 
August  7th  and  have  been  on-going  activities  ever  since. 

Expansion  of  the  "input  side"  of  the  EDB  included  the 
initiation  of  data  entry  for  CTA  and  PATCO  in  November  1979,  and 
for  NYCTA  in  February  1980.  In  spite  of  the  later  dates  for  the 
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FIGURE  6-9.  ESTABLISH/OPERATE  EXPERIMENTAL  DATA  BANK  (TASK  8) 


initiation  of  data  entry,  these  properties  also  submitted 
historical  data  so  that  the  EDB  contains  data  going  back  to  July 
1,  1979,  for  BART,  NYCTA,  AND  WMATA,  and  August  1,  1979,  for  CTA 
and  PATCO. 

The  first  EDB  Output  Report  was  published  in  September, 
1979,  and  contained  the  July  data  from  BART  and  WMATA.  The  TRIP 
Liaison  Board  reviewed  the  report  and  recommended  several 
modifications  to  format  and  content.  EDB  Output  Reports  were 
subsequently  published  during  Task  8 in  November,  1979  (August 
and  September  data),  March,  1980  (November,  1979,  data)  and 
July  1980  (March  data). 

It  was  on  the  "output  side"  of  the  EDB  where  emphasis  on  the 
"experimental"  nature  of  the  data  bank  occurred.  Each  EDB  Output 
Report  was  a major  revision  of  the  previous  report  in  terms  of 
both  format  and  content.  Methods  of  presenting  the  data,  level 
of  detail,  accuracy  and  validity,  statistical  significance,  all 
of  these,  and  more,  were  of  concern  to  the  Liaison  Board  members, 
and  their  concern  was  reflected  in  the  high  level  of  interest 
expressed  in  the  presentation  of  information  from  the  EDB. 

At  the  8th  meeting  of  the  TRIP  Liaison  Board  (July  1980), 
the  EDB  Output  Report  format  was  changed  from  one  volume  having 
seven  sections  to  seven  separate  volumes,  one  for  the  industry, 
and  one  for  each  of  the  six  participating  properties.  This 
format  has  remained  in  effect  ever  since. 

The  first  "Special  Reports"  were  also  presented  to  the 
Liaison  Board  at  their  8th  meeting.  Three  reports  were  produced 
for  this  meeting.  The  first  report  contained  a detailed  (by 
Generic  Part  Number)  inventory  of  data  records  contained  in  the 
TRIP  Data  Base  for  the  period  January  1 - March  31,  1980.  The 
second  Special  Report  contained  a recapitulation  of  the  detailed 
Data  Base  inventory  showing  the  results  aggregated  to  the  3rd, 
4th,  and  5th  (of  8)  levels  of  indenture  in  the  Generic  Part 
Number.  This  report  was  incorporated  into  the  monthly  Output 
Report  by  the  Liaison  Board  at  that  meeting.  The  Third  Special 
Report  displayed,  in  a matrix  format,  the  data  elements  being 
provided  by  each  property  in  each  of  the  four  dynamic  data  record 
types . 

When  the  period  of  performance  for  Task  8 expired  in 
September  1980,  EDB  operation  transferred  to  Task  12  of  the 
contract . 


6.9  TASK  9 — MODIFY/IMPROVE  TRIP  OPERATING  PROCEDURES 

The  activities  of  Task  9 are  illustrated  in  Figure  6-10. 
The  major  objective  of  Task  9 was  to  monitor  the  operation  of  the 
Experimental  Data  Bank  for  the  purpose  of  identifying  areas  in 
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which  improvement  could  be  made. 

The  TRIP  Data  Bank  definition  that  emerged  from  Tasks  1 - 4 
was  used  as  the  cornerstone  for  EDB  implementation  in 

Tasks  7 & 8.  Many  of  the  operating  procedures  defined  in  the 
earlier  stages  of  the  program  were  quite  speculative  in  nature 
since  there  was  no  previous  industry  experience  with  a data  bank 
of  the  size  and  scope  of  that  being  developed  for  TRIP. 
Similarly,  data  definitions  were  provided  in  vacuo  by  each 
property  without  consideration  of  subtle  variances  within  the 
industry.  These  subtleties  were  not  exposed  until  after  EDB 
operation  had  commenced  and  the  first  Output  Report  published. 

Publication  of  Output  Reports  from  the  EDB  has  thus  been  a 
major  source  of  input  for  system  modifications.  The  Liaison 

Board  had  been  unable  to  reach  agreement  within  itself  during  the 
early  design  stages  of  the  TRIP  Data  Bank  regarding  the  format 
and  content  of  output  reports.  A "first  cut"  was  subsequently 
made  by  DRC  and  presented  to  the  Liaison  Board  in  the  EDB  Output 
Report  for  the  Month  of  July  1979,  DRC  Report  Number  E-5206U. 

The  5th  TRIP  Liaison  Board  meeting,  which  was  held  in 
September  1979,  marked  a turning  point  in  the  program.  With  the 
July  Output  Report  in  hand,  the  Liaison  Board  was  stimulated  into 
thinking  in  more  concrete  terms  about  the  reporting  capability  of 
TRIP.  The  emphasis  on  Output  Report  refinement  has  remained  ever 
since . 

In  addition  to  improvements  inspired  by  "external"  stimuli, 
many  changes  were  also  made  to  make  the  EDB  software  more 

cost-effective  to  operate.  Various  software  "modules"  were 
linked  into  logical  jobstreams  to  eliminate  stop/restart  delays. 
"Permanent  files",  which  formerly  had  been  used  to  pass  data  from 
one  software  module  to  another,  were  converted  to  "temporary 
files"  which  exist  only  while  the  jobstream  is  being  executed 
thus  reducing  system  storage  costs  on  the  computer. 

On-line  storage  of  the  Data  Base  file  itself  became  the  cost 

high-driver  after  only  a few  months  of  EDB  operation.  Storage 

costs  were  significantly  reduced  by  convertng  to  magnetic  tape  as 
the  bulk  storage  media  for  the  Data  Base  and  Data  Base 

Dicitonary.  This  change  had  only  a minimal  impact  on  system 
operation  since  all  of  the  software  modules  and  jobstreams  used 
to  manipulate  the  Data  Base  were  "batch  jobs"  which  do  not 
require  on-line  access  to  the  Data  Base. 

Although  the  period  of  performance  for  Task  9 contractually 
expired  in  September  1980,  the  spirit  of  Task  9 remained  as  EDB 
operation  transitioned  into  Tasks  11  & 12  (Contract  Phase  II). 
Funding  allocations  for  Tasks  11  & 12  were  sufficient  to  maintain 
a nominal  level  of  EDB  refinement  and  enhancement,  and  most  of 
this  effort  has  gone  into  accomodating  the  desires  of  the  Liaison 
Board  with  regard  to  Output  Report  modification. 
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In  spite  of  a major  snafu  in  the  mileage  data  supplied  by 
CTA  in  July  1980,  the  EDB  Output  Report  for  the  month  of 
June  1980  was  published  in  October.  This  report  marked  the 
beginning  of  "monthly"  Output  Report  production.  At  their  9th 
meeting  in  October  1980,  the  Liaison  Board  expressed  their  desire 
that  DRC  publish  "monthly"  (as  determined  by  scope  and  content) 
EDB  Output  Reports  for  each  calendar  month  as  all  of  the  data 
(including  corrections)  for  a given  month  is  made  available  by 
the  properties.  This  approach  to  routine  report  production 
recognized  the  logistics  problems  inherent  in  a voluntary  program 
and  thus  refrained  from  imposing  a fixed  schedule. 

EDB  enhancement  has  continued  throughout  the  remainder  of 
Contract  Number  DOT-TSC-1 559 • Most  of  the  recent  refinements 
have  been  confined  to  Output  Report  revisions  and  streamlining  of 
the  report  production  process.  Other  areas  of  possible 
improvement  have  been  identified  and  catalogued.  Due  to  limited 
resources  in  the  second  phase  of  the  contract,  however, 
implementation  of  these  improvements  has  been  postponed. 


6.10  TASK  10  --  CRITICAL  DESIGN  REVIEW  PRESENTATION 


The  activities  of  Task  10  are  illustrated  in  Figure  6-11. 
In  the  TSC  Implementation  Plan,  TRIP  consists  of  three  phases: 
Phase  I covers  the  planning,  designing,  and  testing  of  a 
small-scale  transit  reliability  data  bank  for  a select  group  of 
rail  and  bus  vehicle  components;  Phase  II  is  the  establishment 
and  operation  of  a full-scale  reliability  data  bank;  Phase  III  is 
the  expansion  of  Phase  II  to  include  other  classes  of  transit 
equipment . 

The  purpose  of  the  Critical  Design  Review  (CDR)  was  to 
review  Phase  I activities  and  accomplishments,  and  to  assess 
whether  or  not  the  time  was  appropriate  to  commence  with  Phase  II 
of  the  TRIP  Implementation  Plan.  The  CDR  of  TRIP  was  held  at 
APTA  Headquarters  in  Washington,  DC,  on  March  31*  1980.  The  CDR 
Committee,  consisting  of  the  TRIP  Liaison  Board  representatives 
from  the  six  properties  participating  in  the  EDB  operation  and 
repr esentataives  from  APTA,  UMTA,  TSC,  and  DRC  reviewed  the 
preceeding  24  months  of  TRIP  activity.  The  transit  property 
representatives  had  previously  been  requested  to  submit  their 
individual  property's  recommendations  and  comments  concerning  the 
development  and  operation  of  the  EDB  and  future  expansion  of  the 
EDB  into  a full-scale  TRIP  Data  Bank. 

The  general  concensus  of  the  EDB  property  representatives 
was  that  TRIP  is  a worthwhile  program  and  should  be  continued. 
Specific  comments  concerning  the  near-term  future  of  TRIP  are 
highlighted  below: 
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FIGURE  6-11.  CRITICAL  DESIGN  REVIEW  (CDR)  PRESENTATION  (TASK  10) 


9 The  full  benefit  of  TRIP  has  yet  to  be  realized  --  the 
major  benefits  will  be  derived  from  long-term  operation 
of  the  Data  Bank; 

9 Dynamics  Research  Corporation  (DRC)  should  continue  to 
operate  the  TRIP  Experimental  Data  Bank  for  an  additional 
year  in  order  to  allow  more  time  to: 

explore  the  full  potential  of  the  system; 

develop  output  reports; 

refine  system  operation; 

develop  more  confidence  in  the  system; 

9 A second  CDR  should  take  place  one  year  hence  to  again 
consider  the  timing  of  EDB  expansion  into  a full-scale 
system . 


A full  transcript  of  the  proceedings  from  the  technical 
discussions  of  the  TRIP  CDR  is  contained  in  DRC  Report  Number 
E-5505U. 


Participation  and  interest  in,  as  well  as  potential  benefits 
from,  Phase  I indicate  that  TRIP  EDB  users  (operating  properties, 
consultants.  Federal  Government,  and  suppliers)  want  factual 
information  from  TRIP  and  are  relying  on  TRIP'S  large  quantity  of 
readily  available  maintenance  data  to  provide  timely  reports  of 
equipment  replacement  experience. 

Pending  a favorable  decision  from  the  final  Phase  I CDR, 
Phase  II  will  start  a full-scale  merged  RRV  and  Bus  TRIP  Data 
Bank.  It  will  be  established  and  put  on-line  starting  with  the 
transfer  of  data  from  the  RRV  and  Bus  EDBs . The  number  of 
equipments  initially  monitored  will  be  small,  but  as  the 
capability  expands,  additional  equipments  will  be  monitored  until 
failure  data  on  all  vehicle  components  are  contained  in  the  Data 
Bank . 


A CDR  of  Phase  II  can  then  be  performed  to  determine  if 
Phase  II  accomplished  its  goals  and  if  Phase  III  is  justified. 
Phase  III  is  envisioned  as  the  expansion  of  the  Data  Bank  and 
equipment  monitored  to  cover  UMTA  responsibilities  in  Fare 
Collection,  ATO/ATC,  and  track  and  structures.  As  other 
transportation  equipments  are  incorporated,  the  TRIP  Data  Bank 
will  become  the  UMTA  National  TRIP. 
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REPORT  OF  NEW  TECHNOLOGY 


A significant  amount  of  rail  transit  equipment  reliability 
data  was  collected  which  aided  in  the  establishment  of  a national 
transit  reliability  Data  Bank.  The  Data  Bank  will  promote  the 
amalgamation  of  current  reliability  efforts  within  the  transit 
industry;  provide  a focal  point  for  a consolidated  reliability 
effort;  and  assist  the  transit  industry  in  creating,  developing, 
and  improving  revenue  service  operations. 
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